Build-System
-
make ist easy, zumindest wenn du es nicht platformunabhängig haben willst (denn dann geht dieser weg weiter zu den auto-tools). Bei make gibt's auch schon viele fertige, "implizite Regeln", die man einfach ausnutzen kann.
Mit all dem anderen, was es da neben make noch gibt, bin ich nicht richtig warm geworden: SCons, waf (the meta build system), CMake, Boost.Build. -- Meist habe ich dabei die Dokumentation verflucht oder fand es blöd, dass diese Build-Scripte trotzdem so lang werden order noch irgendwelche Module nachladen müssen. Man sollte doch erwarten, dass man mit 'nem modernen Build-Werkzeug, die "Bauanleitung" halbwegs plattformunabhängig, kurz und deklarativ aufschreiben können sollte. Aber spätestens dann, wenn es darum geht, wo man seine Bibliotheken her holen soll, wo die Incdlude-Dirs liegen und so, wird es nervig -- zumindest in der Windows-Welt, wenn man nicht Cygwin oder MinGW nachgerüstet hat.
Ich fand eigentlich den Ansatz mit make + pkg-config ganz nett. Unter Unix-artigen Betriebssystemen funktioniert das ganz gut, sofert bei Installation von irgendwelchen Bibliotheken inklusive der Developerversionen (mit Header und Co) automatosch diese .pc-Dateien mit entsprechender Metainformation mitinstalliert werden.
-
Nexus schrieb:
Das Makefile-Format ist vor allem auf Unix fokussiert und wird nicht von allen Compilern unterstützt.
Da hast Du aber was missverstanden. Es gibt keinen Compiler, der das Makefile-Format unterstützt. Das Makefile steuert den Aufruf des Compilers. Der Compiler hat damit gar nichts am Hut.
-
Richtig, war schlecht ausgedrückt.
Was ich eigentlich meinte, ist dass simple Makefiles nicht ausreichen, wenn du compilerübergreifend arbeiten willst. Daher gibts auch die Meta-Buildsysteme wie CMake. Diese generieren dann Makefiles, NMake-Files, Visual-Studio-Solutions, Code::Blocks-Projekte oder was auch immer.
-
@Nexus
Immer noch schlecht ausgedrückt
Man kann auch Makefiles schreiben die mit mehreren Compilern klarkommen.
Man bleibt nur immer vom Make-Tool abhängig.Es wäre theoretisch kein Problem das MinGW oder Cygwin Make mit Visual C++ zu verwenden.
Wenn man ein Makefile hat das passende Switches für verschiedene Compiler enthält, z.B. 1x für GCC/Clang und 1x für MSVC, dann kann man auch das verwenden um plattformübergreifend und compilerübergreifend zu bauen.Das grösste Problem dabei wird aber vermutlich sein, dass es keinen Windows Anwender interessiert das MinGW oder Cygwin Make Tool zu verwenden
-
Aber du musst dennoch einiges mehr tun als mit CMake. Gerade wenn du Bibliotheken linkst, kann CMake relativ gut abstrahieren, und du musst die compiler-spezifischen Kommandozeilenbefehle nicht kennen. Wo die Abstraktion oft nicht mehr reicht, sind spezielle Konfigurationen wie statische Runtime oder die Deaktivierung von Warnungen etc.
Was würdest du selbst sagen, ist der Vorteil von Metabuildsystemen (CMake) gegenüber Makefiles?
-
Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x und C++11) in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Nexus schrieb:
Was würdest du selbst sagen, ist der Vorteil von Metabuildsystemen (CMake) gegenüber Makefiles?
Bin mir nicht sicher ob es Sinn macht zwischen Metabuildsystemen und Buildsystemen zu unterscheiden.
Der einzige Vorteil den das "meta" bringen kann (aber nicht muss), ist dass man Project/Solution Files für die IDE seiner Wahl erzeugen lassen kann.
Wobei es meist nicht zurück geht - also die Änderungen die man über die IDE gemacht hat kann man meist nicht automatisiert zurück in das Buildfile des Metabuildsystems bringen.Für mich ist Make ein Tool das in die gleiche Gruppe gehört wie CMake, Scons oder Boost Build. Nur dass Make halt ein besonders schlechtes solches Tool ist
-
Ich habe mit make keine guten Erfahrungen gemacht. Ich schaffe es nie, dass das neu kompiliert wird was neu kompiliert werden muss. Es ist beim Arbeiten mit make standard, dass man make clean all machen muss, weil sonst irgendwas nicht aktualisiert wurde. Stell ich mich nur zu blöd an?
-
-
nwp3 schrieb:
Ich habe mit make keine guten Erfahrungen gemacht. Ich schaffe es nie, dass das neu kompiliert wird was neu kompiliert werden muss. Es ist beim Arbeiten mit make standard, dass man make clean all machen muss, weil sonst irgendwas nicht aktualisiert wurde. Stell ich mich nur zu blöd an?
Ja, anscheinend schon.
Du musst Make natürlich mitteilen, welche Ausgaben von welchen Eingabedateien abhängen. Tust du das nicht (oder nur unvollständig), kommen solche Sachen bei raus.
