Ich habe das Gefühl, dass die gesamte CMake-Community mich trollt. Keines der "Tutorials" oder Ressourcen macht mir einen Sinn. Es ist wie ich etwas vermisse. Ich denke, was mich am meisten verwirrt, ist die Sprache, und keines der Tutorials, die ich gesehen habe, kommt sogar dazu, anständig zu sein, jemandem, der wenig Erfahrung hat, CMake zu erklären.
Wie auch immer, ich arbeite mit FireBreath und es benutzt CMake ausgiebig. Ich denke, es ist an der Zeit, herauszufinden, wie man es benutzt, anstatt die Projektdateien direkt zu verändern.
Die CMakeLists.txt-Stammdatei enthält Folgendes:
%Vor% Ich würde wirklich es schätzen, wenn mir jemand jede Zeile erklären könnte. Vor allem, was ${GENERAL} und ${GENERATED} sind.
Zunächst einmal ist die cmake-Syntax wirklich einfach. Es besteht aus "Befehlen" und "Argumenten". Es ist so einfach, dass es eine Weile dauert, bis es einsinkt. Alles ist "Befehl (Argumente)". Außerdem wird bei Befehlsnamen die Groß- / Kleinschreibung nicht beachtet. Früher mussten sie ALLE CAPS sein, aber seit Version 2.6 (denke ich) spielt es keine Rolle. Argumente sind jedoch Groß-und Kleinschreibung.
%Vor%Dieser Befehl legt die minimal erforderliche Version von cmake für ein Projekt fest. Wenn die aktuelle Version von cmake kleiner als 2.6 ist, wird die Verarbeitung gestoppt und ein Fehler gemeldet. Dies verhindert, dass alte Versionen des Tools unterstützt werden müssen.
%Vor% Setzen Sie die Variable CMAKE_BACKWARDS_COMPATIBILITY auf den Wert 2.6. Dies ist ein kleiner Fehler in der CMakeLists.txt-Datei, die Sie vorgestellt haben, da CMAKE_BACKWARDS_COMPATIBILITY nicht für 2.6 und höher verwendet werden sollte. Das Skript sollte wahrscheinlich cmake_policy verwenden. Hiermit wird festgelegt, wie neuere Versionen von cmake sich bei Inkonsistenzen in früheren Cmake-Versionen verhalten sollten. Alle Skripte, die Sie heute von Grund auf schreiben, müssten sich darüber keine Gedanken machen.
Setzt den Projektnamen auf den Wert der Variablen PLUGIN_NAME . Dieser Wert wird in einigen IDEs als Projektname angezeigt. Um einen Wert in eine Variable zu schreiben, können Sie set(PLUGIN_NAME myName) verwenden und den Wert lesen, den Sie mit der ${} Syntax verwenden: "${PLUGIN_NAME}" . Einige Befehle schreiben auch in Variablen, aber Sie verwenden sie genauso wie im Befehl set .
file ist ein Befehl. Das erste Argument GLOB bedeutet "gebe Dateien auf dem Datenträger zurück, deren Namen mit den Mustern übereinstimmen, die ich als Argumente angeben werde". Das nächste Argument GENERAL ist die Variable, in der das Ergebnis gespeichert wird. Wie bei set schreibt es das Ergebnis in die Variable und Sie können es später mit ${GENERAL} lesen. RELATIVE und der Pfad bedeutet, dass die Dateinamen relativ zu diesem Pfad zurückgegeben werden, nicht der vollständige Pfad. Also statt "C: \ some \ long \ Pfad \ src \ foo.cpp" oder "/home/me/some/path/src/foo.cpp" würden Sie "src \ foo.cpp" oder "src /" erhalten foo.cpp ". Die Variable CMAKE_CURRENT_SOURCE_DIR ist eine "magische Variable", die CMake für Sie eingibt und sich auf den Pfad zum Quellenverzeichnis bezieht, das gerade verarbeitet wird und in dem sich diese CMakeLists.txt-Datei befindet. Die letzte Liste von Argumenten sind die Muster von Dateien, die abgeglichen werden. Grundsätzlich alles, was die Dateiendung cpp, h oder cmake hat.
Fügen Sie die Verzeichnisse in ${PLUGIN_INCLUDE_DIRS} zu denen hinzu, die der Compiler nach Include-Dateien durchsucht. Dies führt zu zusätzlichen "-I" Argumenten, wenn Sie zum Beispiel mit gcc kompilieren.
Zeilen, die mit # beginnen, sind Kommentare.
%Vor% Dateien können Schlüssel / Wert-Paare zugeordnet haben, und dies wirkt sich auf ihre Erstellung aus. Hier haben die Dateien in der Variable ${GENERATED} die Eigenschaft "GENERATED" auf den Wert 1 gesetzt. Was bedeutet das? Nun, CMake weiß nun, dass man die Dateien "$ {GENERATED}" nicht auf der Festplatte suchen muss, da sie in einem anderen Build-Schritt erstellt werden. Im veröffentlichten Snippet setzt niemand die Variable ${GENERATED} . Ich stelle mir vor, dass es anderswo in den Projektdateien gesetzt wird. Verwechseln Sie nicht die Variable ${GENERATED} mit der Eigenschaft GENERATED! Dies ist ein subtiler Punkt, und vielleicht sollte die Variable GENERATED_FILES sein, um Verwirrung zu vermeiden, d. H.% Co_de%.
Dies erstellt eine Gruppe, die in Visual Studio in eine Dateiregisterkarte namens "Generated" übersetzt wird, die die Dateien in der Variablen SET_SOURCE_FILES_PROPERTIES(${GENERATED_FILES} PROPERTIES GENERATED 1) enthält.
Diese Zeile setzt die Variable SOURCES auf den Wert in den Variablen ${GENERATED} und ${GENERAL} . Zuvor haben wir ${GENERATED} als Liste der cpp, h und cmake Dateien im aktuellen Quellverzeichnis festgelegt. In einem C-ähnlichen Pseudocode ist dies wie "SOURCES = GENERAL + GENERATED". Als Detail der Implementierung ist der Wert SOURCES tatsächlich eine Liste und sein Inhalt wird durch ";" Figuren. Normalerweise wird dies getan, damit Sie später eine Bibliothek oder eine ausführbare Datei erstellen können, indem Sie einfach die Variable ${GENERAL} verwenden, anstatt die anderen 2 Variablen überall zu wiederholen.
Manchmal kann ich deine Gefühle über die CMake-Tutorials verstehen. Ich empfehle, die Online-Dokumente und einige cmake-Projekte zu betrachten: z. Oger, Vtk, Kde.
Aus dem Aussehen Ihrer CMakeLists.txt sieht es so aus, als ob dieses von einem externen CMake-Projekt (mit add_subdirectory) aufgerufen werden soll, da es sich auf die Variablen PLUGIN_NAME, PLUGIN_INCLUDE_DIRS und GENERATED bezieht.
Um Ihre Fragen zu beantworten:
%Vor%Dies bereitet Ihre cmakefile vor, teilt cmake mit, dass es Version 2.6 oder höher sein muss und dass Sie ein Projekt mit einem Namen starten, wie er in der Variablen PLUGIN_NAME angegeben ist.
%Vor%Dieser Teil klopft durch das aktuelle Quellverzeichnis (das Verzeichnis, in dem Sie cmakelists.txt sind) und sammelt ALLE * .cpp, * .h und * .cmake Dateien. Das Ergebnis ist ein Satz / eine Liste von Dateipfaden, relativ zum aktuellen Quellverzeichnis und wird in einer Variablen GENERAL gespeichert.
%Vor%Offensichtlich wird es eine Reihe von Quelldateien in der Variable GENERATED (also nicht GENERAL) geben. Im Falle von Build-generierten Quelldateien sind diese Dateien nicht unbedingt beim ersten Build von CMake vorhanden und CMake muss wissen, dass diese generiert werden. Mit dem Befehl set_source_files_properties erhalten sie die Eigenschaft "generated", die für CMake benötigt wird, um die korrekte Abhängigkeitsprüfung durchzuführen.
%Vor%Nun haben wir einen Satz von Quelldateien aus dem Dateiaufruf (GLOB ...), der in der Variablen GENERAL gespeichert ist. Und wir haben eine Reihe von soruce-Dateien in der Variable GENERATED gespeichert, die woanders erstellt wird. Diese beiden Sätze werden in einer einzigen Liste von Quelldateien zusammengefasst und in der Variablen SOURCES gespeichert.
Unter normalen Umständen würde ich einen Aufruf von add_library erwarten: add_library ($ {PLUGIN_NAME} {QUELLEN})
Dies gibt Cmame an, dass eine neue Bibliothek aus den Quelldateien in SOURCES erstellt und erstellt werden soll.
Tags und Links cmake firebreath