Ich habe ein interessantes Henne-Ei-Problem und eine mögliche Lösung dafür (siehe meine Antwort), aber diese Lösung verwendet CMake auf ungewöhnliche Weise. Bessere Alternativen oder Kommentare wären willkommen.

DAS PROBLEM

Die einfache Version des Problems kann als einzelnes CMake-Projekt mit den folgenden Merkmalen beschrieben werden:

Eines der Build-Ziele ist eine ausführbare Befehlszeile, die ich @ nennen werd mycomp, dessen Quelle sich in einem @ befindmycompdir und Änderungen am Inhalt dieses Verzeichnisses sind nicht möglich. Das Projekt enthält Textdateien (ich nenne siefoo.my undbar.my) welche brauchen mycomp Führen Sie sie aus, um eine Reihe von C ++ - Quellen und -Headern sowie einigeCMakeLists.txt -Dateien, die Bibliotheken definieren, die aus diesen Quellen erstellt wurden.Weitere Build-Ziele im selben Projekt müssen mit den Bibliotheken verknüpft werden, die von den generierten @ Bibliotheken definiert wurdeCMakeLists.txt Dateien. Diese anderen Ziele haben auch Quellen, die#include Einige der generierten Header.

Sie können sich vorstellen mycomp als so etwas wie ein Compiler und die Textdateien in Schritt 2 als eine Art Quelldatei. Dies stellt ein Problem dar, da CMake das @ benötigCMakeLists.txt Dateien zur Konfigurationszeit, aber mycomp ist erst zur Erstellungszeit verfügbar und daher nicht beim ersten Start verfügbar, um das @ zu erstelleCMakeLists.txt Dateien früh genug.

NICHT ANTWORT:

Normalerweise wäre eine auf ExternalProject basierende Superbuild-Anordnung eine mögliche Lösung, aber das oben Gesagte ist eine erhebliche Vereinfachung des eigentlichen Projekts, mit dem ich mich befasse, und ich habe nicht die Freiheit, den Build in verschiedene Teile aufzuteilen oder andere durchzuführen umfangreiche Umstrukturierungsarbeiten.