CMake-generierte Dateien: Build-Reihenfolge von Regenerierungsabhängigkeiten trennen

Worum es geht

Eine generierte Datei braucht eine erzeugende Regel, deklarierte Eingaben und eine konsumierende Stelle. CMake unterscheidet eine Abhängigkeit auf Zielebene, die Ziele in eine Reihenfolge bringt, von einer Abhängigkeit auf Dateiebene, die eine Regenerierung auslösen kann. Einen Generator nur über einen Target-File-Ausdruck zu erwähnen, liefert nicht beides. Die Dokumentation zu benutzerdefinierten Befehlen unterscheidet zudem Hauptausgaben von Nebenprodukten. CMake add_custom_command

Warum es wichtig ist

Behebt ein Agent einen fehlenden Header durch Hinzufügen einer breiten Build-Abhängigkeit, kann der nächste saubere Build gelingen, während ein bearbeitetes Schema dennoch veralteten Code hinterlässt. Den Fehlschlag als fehlende Kante im Build-Graphen behandeln. Die unten vorgeschlagene Überprüfung fragt, welche Änderung jedes generierte Artefakt ungültig macht.

So wird es angewendet

• Einen kleinen Graphen zeichnen, der Schema, Generator-Executable, generierte Quelldatei und konsumierendes Ziel enthält. Reihenfolgekanten getrennt von Regenerierungskanten kennzeichnen.
• Jeder generierten Ausgabe eine einzige zuständige Regel geben. Bei mehreren konsumierenden Stellen ein gemeinsames Generierungsziel einführen, statt den Befehl in jede konsumierende Stelle zu kopieren.
• Schema und Generator in den passenden Abhängigkeiten auflisten; sekundäre generierte Dateien als Nebenprodukte deklarieren. VERBATIM verwenden, wenn Befehlsargumente übergeben werden.
• In einem Wegwerf-Build-Baum Prüfungen für einen sauberen Build, einen unveränderten erneuten Build, eine Schemaänderung, eine Generatoränderung und das Löschen eines Nebenprodukts vorschlagen. Festhalten, welcher Generatorbefehl jeweils tatsächlich läuft.
• Den relevanten Build mit paralleler Ausführung und Pfaden mit Leerzeichen wiederholen. Sowohl den generierten Inhalt als auch die Zeitstempel überprüfen, bevor die Änderung akzeptiert wird.

Stolpersteine

Einen inkrementellen Build nicht dadurch «reparieren», dass stets das Build-Verzeichnis gelöscht wird: das beseitigt die Beweise. Ein erfolgreicher erneuter Build ist kein Beleg dafür, dass alle Eingabekanten vorhanden sind. Die Unterstützung von Depfiles und das Verhalten von Policies hängen von der gewählten CMake-Version und dem Generator ab. Diese Details für die erklärte Mindestversion des Projekts überprüfen, bevor neuere Optionen hinzugefügt werden.