Themen-Überblick
(Aktualisieren)
| Autor |
Nachricht |
SeppJ
|
Du vergleichst da Äpfel mit Birnen Apfelbäumen. cmake ist kein direkter Ersatz für make. cmake steht eher in Konkurrenz mit den autotools (also der Kombination von autoconf, automake & Co) und anderen Buildsystemen wie z.B. Scons. Also eine Ebene höher als das typische Makefile. |
|
|
 |
Samuel25
|
Zum weiteren Verständnis habe ich mein Makefile mal auf
eine richtige Bibliothek hin angepasst um zu sehen ob es funktioniert.
| Code: | 1
2
3
4
5
6
7
8
9
10
11 | CC = c:/MinGW/bin/g++.exe
CFLAGS = -Wall
CLIBS = -LC:/irrlicht-1.7.2/lib/Win32-gcc -lIrrlicht
OBJ = main.o
all: $(OBJ)
$(CC) $(CFLAGS) -o myLibProg $(OBJ) $(CLIBS)
%.o: %.c
$(CC) $(CFLAGS) -c $< | |
Da dies auch wunderbar funktionierte, habe ich mich mal noch ein Stück weiter vorgewagt, und versucht es auf CMake zu portieren. Und da bin ich wieder beim ursprünglichen Problem: CMake (und die autotools auch, nur dass die NOCH schwerer zu verstehen sind) scheint nur Libraries zu kennen, die direkt aus dem Sourcecode kompiliert werden. Ein Beispiel für einfaches Linken zu einer shared library wie es das Makefile oben macht hat mir Google nicht geliefert.
Kann mir jemand schreiben, wie obiges Makefile mit CMake aussehen würde? |
|
|
|
berniebutt
|
Für die meisten Compiler gibt es komfortable Entwicklungsumgebungen (IDE). Diese nehmen dem Programmentwickler das Erstellen von Makefiles ab. Wenn du die Makefiles verstehen willst, musst du zunächst einen Überblick haben, was ein Compiler und was ein Linker macht. Compiler: Sourcecode (C/C++) --> Binärobjekte (obj). Linker: Binärobjekte --> Programm (exe).
Die Standardbibliotheken werden über Headerfiles mit #include dem Compiler mitgeteilt und vom Linker gebrauchsfertig eingebunden. Eigene unabhängig erstellte Bibliotheken (lib) brauchen etwas mehr: die Funktionsprototypen für den Compiler und die Benennung der LIB-Files für den Linker.
Verstehe erst einmal dies! |
|
|
|
Unregistrierter
|
| Samuel25 schrieb: | Eigentlich funktioniert es so auch, nur dass ich in meinem Projekt den header über '#include "myLib/myLib.h"' inkludieren musste, damit er gefunden wird. Ist es also notwendig immer den ganzen Pfad zum Header anzugeben?
Und habe ich das richtig verstanden, dass wenn man dem Compiler die Library und dem Sourcefile den Standort der Library-Header mitgeteilt hat einfach die Funktionen der Bibliothek verwenden kann, ohne weitere Schritte? |
1. Du musst immer einen include machen, wenn du eine lib benutzt!
2. Solltest du auf keinen Fall irgendwelche Pfade im Header angeben, weil das auf unterschiedlichen Rechnern zu Problemen führen kann! Mache das stattdessen über den Linker, in dem zu ihm mitteilst, wo er suchen muss. Das kannst du übrigens auch wunderbar über gcc machen, der dann den Linker für dich aufruft. Mit -L gibst du den Ordner an, wo der Linker nach einer lib suchen soll. Mit -ldeinLibName, gibst du den Libnamen an, wobei erwartet wird, dass deine lib mit "lib" anfängt und in deinem Fall mit ".so" endet. WICHTIG: Bei der Option -ldeinLibName lässt du das "lib" vorne und das ".so" hinten weg!
L. G.
Steffo |
|
|
|
_kermit
|
| hustbaer schrieb: | immer diese pseudo-minimalisten.
es reicht auch int foo() {return 1;} |
Warum nicht gleich void f() {}? |
|
|
|
hustbaer
|
immer diese pseudo-minimalisten.
es reicht auch int foo() {return 1;} |
|
|
|
Samuel25
|
Hallo nochmal, und Danke für die bisherigen Antworten.
Ich habe mir den Hinweis zu Herzen genommen und ersteinmal eine eigene kleine Library geschrieben. Dazu habe ich die Library mit "g++ -c myLib.cpp -o myLib.o" kompiliert und anschließend mit "ld -shared myLib.o -o libmyLib.so" gelinkt (ich habe mich für eine shared library entschieden, da der Kompiler sonst einfach nur die object-Datei wie jedes andere Objekt meines projektes einfach integriert hätte). Danach habe ich folgendes Makefile geschrieben:
| Code: | 1
2
3
4
5
6
7
8
9
10
11 | CC = /usr/bin/g++
CFLAGS = -Wall
CLIBS = -LmyLib -lmyLib
OBJ = main.o
all: $(OBJ)
$(CC) $(CFLAGS) -o myLibProg $(OBJ) $(CLIBS)
%.o: %.c
$(CC) $(CFLAGS) -c $< | |
Folgend habe ich mein Projekt mit make kompiliert und noch die libmyLib.so nach /usr/lib kopiert, damit mein Programm sie finden kann. Eigentlich funktioniert es so auch, nur dass ich in meinem Projekt den header über '#include "myLib/myLib.h"' inkludieren musste, damit er gefunden wird. Ist es also notwendig immer den ganzen Pfad zum Header anzugeben?
Und habe ich das richtig verstanden, dass wenn man dem Compiler die Library und dem Sourcefile den Standort der Library-Header mitgeteilt hat einfach die Funktionen der Bibliothek verwenden kann, ohne weitere Schritte? |
|
|
|
Mach eigene lib
|
Am meisten würde dem TS helfen, wenn er mal seine eigene kleine Bibliothek erstellt und compiliert.
Die muss auch nicht viel können.
pow(x,y);
add(x,y);
sub(x,y);
div(x,y);
reicht eigentlich schon und diese lib sollte er dann mal von einem Testprogramm aus nutzen. |
|
|
|
Unregistrierter
|
- Eine Library kann kompiliert sein. Muss aber nicht.
| Zitat: | | An welcher Stelle wird die Library in mein Projekt eingebunden? |
Du includierst erst mal nur den Header. Der Compiler muss wissen, wo die Library liegt.
| Zitat: | An welcher Stelle wird die Library in mein Projekt eingebunden?
Sagen wir, wir haben eine libraryX mit der Funktion fooX()und linken
diese zu unserem Projekt. Kann man dann fooX() einfach aufrufen, nachdem
man sie bekannt gemacht hat (z.B. mit #include "libraryX.h")? |
Ja.
| Zitat: | Woher weiß mein Sourcefile dann, wo die libraryX.h liegt und
welchen Zusammenhang gibt es überhaupt zwischen header files und
object files? |
Das musst du dem Compiler mitteilen. Siehe -L und -I Option im gcc.
Zwischen Header- oder Object-Files gibt es keinen direkten Zusamenhang. Object Files wurden in Maschinencode kompiliert und man kann einzelne Object-Files zu einer größere ausführbaren Datei "zusammenschmelzen" lassen. Das geht auch wieder über den Compiler.
| Zitat: | | Ein Link zu einer Seite über den allgemeinen Aufbau eines Makefiles würde mir aber eher weniger helfen. |
Doch, das würde dir ungemein helfen!
L. G.
Steffo |
|
|
|
SeppJ
|
| 01:26:58 01.05.2012 Titel: |
Re: Builtsysteme verstehen |
Zitieren |
| Samuel25 schrieb: |
Entschuldigt den langen Text, aber ich wüsste nicht wie
ich es kürzer hätte fassen sollen.
|
Ein
erster
Schritt
wären
weniger
Z
e
i
l
e
n
u
m
b
r
ü
c
h
e
. |
|
|
|
|
|
|
|
|
Twitter
Facebook