Archiv verlassen und diese Seite im Standarddesign anzeigen : Sauberes Makefile C++
Hallo,
ich habe ein Projekt mit vielen C++ sourcen und auch einigen C-Sourcen. Alles ist per Hand gemacht also keine GUI oder sonst was was mir alles selber machen würde.
Alles kompiliert durch. Nur frage ich mich wie ein sauberes Projekt sowohl von der Verzeichnisstruktur aussieht, also auch wie ich ein sauberes Makefile bauen kann.
ich sehe des öfteren in projekten einen /bin ordner, einen /src ordner, dann aber auch manchmal einen /include ordner. Ich weiß leider nich wozu z.B der include ordner sein sollte?
Zusätzlich würde ich gerne wissen wie ich mit Libraries umzugehen habe. Macht es da sinn die Library zu kompilieren und als ganzes im projektordner zu verfrachten und dann im Makefile einfach nur in diesen Ordner zu verweisen?
Kann mich jemand diesbezüglich aufklären bzw. ein suaberes Makefile zeigen?
Ich wäre sehr dankbar
Grüsse
In den include Ordner haun machen einfach die .h (bzw. .hpp) Datein. Meistens ist aber alles was da drin ist als public interafce anzusehn. Also wenn das Projekt eine lib ist, dann ist das interface der lib in include deklariert. Alle anderen .h files sind nur intern gebracuht. Aber im wesentlichen ist jedem selbst überlassen wie er es am besten strukturiert findet.
musketaquid
27-10-2007, 18:16
Nur frage ich mich wie ein sauberes Projekt sowohl von der Verzeichnisstruktur aussieht, also auch wie ich ein sauberes Makefile bauen kann.
Bei größeren Projekten wäre es sinnvoll Autotools zu benutzen. Hier gibts sogar ein kleines HowTo im Forum ;) Autotools HowTo (http://www.mrunix.de/forums/showthread.php?t=33699&highlight=makefile)
danke ich kann das tutorial ohne probleme nachmachen.
Ich habe so aber noch mehrere Fragen:
1) Ich würde gerne in meinem C++ Projekt einige C-Dateien verwenden.
Mit dem Tutorial geht das so nicht ohne weiteres. Benenne ich die C-Dateien einfach nur in C++ Dateien um, läufts durch. Gibt es eine Sauberere Alternative wie ich es mit automake etc. schaffe?
2) Heißt das, dass ich wenn ich änderungen in irgendeinem meiner C++ files mache, dass ich immer erst /bootstrap, dann configure und dann make aufrufen muss?
3) Wie schaffe ich es, dass das Target, also das fertige Kompilat in einem eigenen /bin - Ordner zu liegen kommt?
4) wie kann ich die Ordnerstruktur sauber halten, es entstehen viele files z.B ein haufen an config.h.in und depcomp und install-sh etc....kann ich die evtl. alle removen nach einem kompilierungsbefehl. Wenn ja - was muss ich dazu tun?
5) wie kann ich denn den compiler ändern? Also ich habe eine MPI-Anwendung deren compiler mpicxx ist. Wie kann ich das jetzt über automake zugänglich machen oder was muss ich tun damit die files mit mpicxx kompiliert werden?
Ich danke euch:)
afaik kannst du deiner Umgebung per Umgebungsvariable CXX einen C++-Compiler angeben (CC für C-Compiler)
Subjektive Meinung (die ich aber anscheinend mit vielen anderen teile):
Alles nur nicht autohell! Das KDE Projekt verwendet z.B. CMake (http://www.cmake.org/), bei blender gibts Leute die die verschiedensten Systeme bevorzugen und somit verwenden sie CMake, SCons (http://www.scons.org/) und reine Makefiles. Dann gibts auch noch Waf (http://www.freehackers.org/~tnagy/bksys.html) (ein SCons rewrite das mehr kann).
SCons (und auch Waf) ist in python geschrieben und die SConstruct Datein sind eigentlich auch python scripts. Man hat also die Mächtigkeit von python im Buildsystem und das Buildsystem lässt sich auf OOP Art erweitern (z.B. eigene Builder für das erstellen von .rpm/.deb Datein hinzufügen). Builder für Qt sind schon mit dabei.
CMake kann dafür als Output nicht nur Makefiles erzeugen, sondern auch Visual Studio und KDevelop Projekte.
Wikipedia: CMake (http://en.wikipedia.org/wiki/CMake), Scons (http://en.wikipedia.org/wiki/SCons), Waf (http://en.wikipedia.org/wiki/Waf)
Freshmeat: Make alternatives (http://freshmeat.net/articles/view/1715/), Stop the autoconf insanity! Why we need a new build system (http://freshmeat.net/articles/view/889/).
anda_skoa
28-10-2007, 16:26
4) wie kann ich die Ordnerstruktur sauber halten, es entstehen viele files z.B ein haufen an config.h.in und depcomp und install-sh etc....kann ich die evtl. alle removen nach einem kompilierungsbefehl. Wenn ja - was muss ich dazu tun?
Das beste ist immer, nicht im Sourceverzeichnis zu kompilieren, sondern in einem getrennten Buildverzeichnis.
D.h. wenn deine Verzeichnisstruktur z.B. so aussieht
project/
project/src
dann einfach ein
project/build
machen und configure (oder einen anderen Makefilebuilder) von dort aufrufen, d.h. im Falle von configure
cd build
../configure
bzw. im Falle von CMake
cd build
cmake ..
Als KDE Entwickler kann ich nur sagen, dass der Umstieg von autotools auf cmake die ganze Sache wesentlich vereinfacht hat, vorallem weil auch viel weniger "administrative" Dateien anfallen, d.h. in der Regel nur eine CMakeLists.txt pro Verzeichnis.
Ciao,
_
undefined
28-10-2007, 17:34
Subjektive Meinung (die ich aber anscheinend mit vielen anderen teile):
Alles nur nicht autohell! Das KDE Projekt verwendet z.B. CMake (http://www.cmake.org/)...........
Mein Subjektive Meinung dazu ist ... Schmarren:D
Ich habe mich jetzt wegen KDE 4 auch mit CMake befassen müssen und hatte so meine Diversen Anfälle.
1) Dokumention ist nie Aktuell oder unvollständig.
2) Für KDE und Qt >= 4.3.1 funzt es nur mit der CVS Version weil DBus und weitere neue Features halt nicht Integriert ist.
3) Die Modules haben jetzt schon 228 Elemente ohne die KDE eigenen Elemente.
4) Wenn die damit fertig sind ist es genauso Unübersichtlich.
Es ist immer wieder das gleiche. Man entwickelt eine neue Scriptsprache die alles einfacher machen soll, und später geht es los. Da fehlt das und dies und hier noch was rein und im entdefekt haben wir wieder etwas mehr wo man sich durch kämpfen muß weil es total unübersichtlich wird!
Man sollte sich eher darauf Konzetrieren das alt bewährte so Optimieren das es merklich einfacher wird.
Noch zusätzlich angemerkt. Gut - es steht jedem Entwickler frei welches Schweinderl er denn gerne nehmen möchte. Aber müssen Enduser denn auch darunter leiden in dem sie vier bis fünf Verschiene Buildsysteme auf ihrem Rechner Installieren müssen automake,ant,cmake,scons und wie sie noch alle heissen ;)
Mein Subjektive Meinung dazu ist ... Schmarren:D
Ich habe mich jetzt wegen KDE 4 auch mit CMake befassen müssen und hatte so meine Diversen Anfälle.Ich muss gestehn ich hab mich mit CMake von der Programmierer Seite noch nicht näher befasst, aber SCons finde ich eigentlich recht gut. Das ist auch keine neu erfundene Programmiersprache sonder einfach Python. Die Syntax von CMake finde ich persönlich auch abstoßend. Aber nicht ganz so sehr als die von den autotools. Mit denen hab ich für ein winzig kleines Progrämmchen mal gekämpft. Bah. Nie wieder. Dann lieber reine Makefiles mit ein paar Shellscripte drum rum. (Oder eben SCons/Waf.)
undefined
29-10-2007, 00:02
Ich muss gestehn ich hab mich mit CMake von der Programmierer Seite noch nicht näher befasst, aber SCons finde ich eigentlich recht gut. Das ist auch keine neu erfundene Programmiersprache sonder einfach Python. Die Syntax von CMake finde ich persönlich auch abstoßend. Aber nicht ganz so sehr als die von den autotools. Mit denen hab ich für ein winzig kleines Progrämmchen mal gekämpft. Bah. Nie wieder. Dann lieber reine Makefiles mit ein paar Shellscripte drum rum. (Oder eben SCons/Waf.)
Mir persönlich ist der einstieg mit shell Kenntnissen bei den autotools recht leicht gefallen. Zumal dank pkg-config (Ein Beweis dafür das man Sinnvolle Verbesserungen sehr wohl in autotools einbringen kann) es viel einfacher geworden ist. Python ist nicht mein fall daher verwende ich diese Tools nur bei der fremd Paket erstellung. Ich würde ganz gerne mal die Meinung mancher KDevelop Entwickler hören die jetzt wieder eine neue Schnittstelle für den Projekt Manager einbringen müssen. Ich habe mich selbst vor einiger Zeit mal mit einer KDE3-IDE für HaXe befasst. Und musste schmerzlich feststellen das ein Projekt Manager eine harte Nuss ist die es zu knacken gilt. Ich warte im Moment auf KDE4 und werde dann einen neuen Anlauf nehmen.
musketaquid
30-10-2007, 13:42
danke ich kann das tutorial ohne probleme nachmachen.Anscheinend hast du es noch nicht einmal gelesen. Denn die meisten deiner Fragen werden dort beantwortet.
1) Ich würde gerne in meinem C++ Projekt einige C-Dateien verwenden.
Mit dem Tutorial geht das so nicht ohne weiteres. Benenne ich die C-Dateien einfach nur in C++ Dateien um, läufts durch. Gibt es eine Sauberere Alternative wie ich es mit automake etc. schaffe?
Was spricht dagegen, in einem C++ Projekt C Dateien mit C++ Endungen zu versehen?
2) Heißt das, dass ich wenn ich änderungen in irgendeinem meiner C++ files mache, dass ich immer erst /bootstrap, dann configure und dann make aufrufen muss?Tja, hättest du richtig gelesen, dann wüsstest du, dass das nur bei Änderungen am Buildsystem notwendig ist, wenn z.B. ein Modul dazu kommt. Bei Änderungen an einer Datei reicht einfach nur make. Hier der Beweis
Im Folgenden werden ein paar Tools aufgerufen, welche Dateien in das Projekt-Verzeichnis kopieren und neue Dateien generieren. Das ist immer Dann notwendig, wenn sich was am Buildsystem ändert, z.B. wenn neue Dateien in den Makefile.am hinzugefügt werden oder configure.in editiert wurde.
4) wie kann ich die Ordnerstruktur sauber halten, es entstehen viele files z.B ein haufen an config.h.in und depcomp und install-sh etc....kann ich die evtl. alle removen nach einem kompilierungsbefehl. Wenn ja - was muss ich dazu tun?
Tja, hättest du richtig gelesen, dann wüsstest du, dass man alle diese Dateien z.B. in einem Verzeichnis config verstauen kann. Hier kannst du nachlesen wie.
(http://www.mrunix.de/forums/showpost.php?p=148929&postcount=3)
anda_skoa
30-10-2007, 16:09
Was spricht dagegen, in einem C++ Projekt C Dateien mit C++ Endungen zu versehen?
Weil sie dann vielleicht irrrtümlich vom Buildsystem als C++ Dateien betrachtet werden und vom C++ Comiler statt vom C Compiler verarbeitet werden.
Ciao,
_
musketaquid
31-10-2007, 12:08
Um so besser! Denn der C++ Compiler ist ein bisschen penibler und deckt Fehler schneller auf. Ich sehe da kein Problem.
Aber wer da ein Problem hat, kann den C++ Compiler ja mit ner "extern C" Anweisung sagen, dass er sich wie ein C Compiler verhalten soll.
Um so besser! Denn der C++ Compiler ist ein bisschen penibler und deckt Fehler schneller auf. Ich sehe da kein Problem.Außer C-Programme müssen dagegen Linken.
Aber da hilft auch:
Aber wer da ein Problem hat, kann den C++ Compiler ja mit ner "extern C" Anweisung sagen, dass er sich wie ein C Compiler verhalten soll.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.