Ninja: Relative Subninja-Pfade werden nicht aufgelöst

Alle Pfade beziehen sich auf das Build-Verzeichnis, nicht auf die Datei, die die subninja-Zeile enthält.

Das macht aber keinen Sinn. Das bedeutet, dass Generatoren _alle_ eine Möglichkeit implementieren müssen, um den Dateien ein Präfix voranzustellen, was bedeutet, dass das Arbeitsverzeichnis geändert werden muss, in dem Befehle ausgeführt werden (was die ursprüngliche Absicht der Build-Konfiguration ändern kann, je nachdem, wie der Generator/die Befehle ausgeführt werden).

Was sind dann die unterschiedlichen Anwendungsfälle für subninja und include ?

Ein Subninja mit Pfaden relativ zur Build-Datei wäre insofern nützlich, als Abhängigkeiten, die so konfiguriert sind, dass sie in ihrem eigenen Verzeichnis ausgeführt werden, dies tun können, ohne ihre Pfade ändern zu müssen, aber dennoch zum Abhängigkeitsdiagramm der übergeordneten Ninja-Konfiguration beitragen können.

Die Funktionalität include wäre unverändert und würde sich genau so verhalten, wie sich Subninjas verhalten, abgesehen davon, dass Regelnamen jetzt in einem kombinierten Namespace sind (wie in #921). Derzeit erreichen subninja und include im Wesentlichen dasselbe, abgesehen davon, dass sie Variablen und Regelnamen definieren ...

Die Idee ist, dass der Generator alle .ninja-Dateien generiert, damit sie Pfade relativ zum Build-Verzeichnis schreiben können. Es ist eine interessante Idee, Ninja-Dateien zu kombinieren, die von verschiedenen Generatoren generiert wurden (es klingt, als ob Sie das tun möchten?), aber das wird derzeit nicht unterstützt.

Richtig, der Unterschied zwischen subninja und include besteht darin, dass ersteres einen Geltungsbereich hinzufügt und letzteres nicht. Der Anwendungsfall dafür ist, dass der Toplevel-Ninja allgemeine Build-Regeln wie cc definieren kann, die auf Variablen wie cflags verweisen, und jeder Subninja kann cflags auf das setzen, was für dieses Ziel angemessen ist, und dort können einmalige Aktionen drin sein. Um ein Beispiel zu sehen, können Sie python misc/write_fake_manifests.py /tmp/foo` ausführen, um eine Reihe von .ninja-Dateien nach /tmp/foo zu schreiben, die dieses Muster verwenden.

Das macht Sinn, obwohl ich immer noch keinen großen Vorteil sehe (außer dem Umfang).

Es ist eine interessante Idee, Ninja-Dateien zu kombinieren, die von verschiedenen Generatoren generiert wurden (klingt so, als ob Sie das tun möchten?)

Exakt. In der Lage zu sein, Ninja selbst als Submodul für meinen Generator und dann ein anderes CMake-Projekt (das für die Ausgabe von Ninja-Build-Dateien konfiguriert ist) einzubinden und dann die Ninja-Konfigurationsdateien für beide zu generieren und sie als subninja einzufügen Die build.ninja -Datei von _my_ project, um sie so erstellen zu können, als ob sie eigenständig wären, aber dennoch meinem Projekt erlauben, ihre Ausgaben (und damit ihre Abhängigkeitsgraphen) zu verwenden, um das gesamte Projekt auf einmal zu erstellen .

Wenn das Sinn macht. Der unmittelbare Anwendungsfall, den ich insbesondere bei meinem Generator sehe, ist, dass er einige Konzepte von Tup (die IIRC einige Designentscheidungen innerhalb von Ninja selbst beeinflusst hat) ausleiht, indem ich N Unterprojekte einbeziehen kann, alle mit ihren eigenen build.ninja Dateien und tippe dann auf ihre Diagramme, damit ich automatisch ein viel größeres Abhängigkeitsdiagramm erstellen kann.

Ich persönlich denke, das würde subninja viel nützlicher machen, obwohl ich sehen könnte, dass es eine potenziell bahnbrechende Änderung ist. Ich sehe jedoch keinen Ausweg, es sei denn, 1) ich ändere die build.ninja -Dateien der Abhängigkeiten mit einem Patch oder 2) opfere die Fähigkeit, die Abhängigkeitsgraphen der Abhängigkeiten zu nutzen.

Die Gedanken?

Wie wäre es mit:

subninja path/to/build.ninja relative path/to

und ein fehlendes relative ist standardmäßig ./ . Das würde es bruchsicher machen, aber dennoch die Funktionalität geben, wenn ein Generator dies wünscht.

Oder vielleicht in die Fußstapfen anderer Ninja-Konstrukte treten

subninja path/to/build.ninja
  relative = path/to

Angenommen, Sie haben ein Projekt unter .../foo und es hat eine Unterverzeichnisleiste, und Ninja hatte die von Ihnen vorgeschlagene relative Pfadlogik.

Wenn Ihr Build-System alle Build-Ausgaben nach /foo/obj schreiben möchte, müsste ein Subninja in /foo/bar, der verzeichnisrelative Pfade verwendet, wissen, dass er seine Ausgabe in ../obj/bar schreiben muss, da dies der Pfad zu ist die Datei aus diesem Unterverzeichnis. Was auch immer Ihre build.ninja-Dateien generiert, muss sich also bereits der globalen Pfadhierarchie bewusst sein. In diesem Fall ist es praktisch dasselbe Problem, alle Pfade relativ zu machen, als würde man den Pfaden im bar/-Verzeichnis ein bar/ voranstellen.

Vielleicht gibt es genug Leute, die Build-Ausgaben in ihre Quellverzeichnisse schreiben, dass das Obige jedoch keine Rolle spielt. Ich höre meistens von Leuten, die eine noch stärkere Trennung wollen – wie die Leute, die Patches an Ninja geschickt haben, damit sie Ninja mit der Build-Ausgabe in einem völlig unabhängigen Verzeichnis bauen können.

Ich bin mir nicht sicher ob ich das verstehe. Subninjas, insbesondere in dem von mir beschriebenen Anwendungsfall, wissen normalerweise nichts über die Struktur des Eltern-Ninjas (zumindest müssen sie es nicht wissen). Ich bin mir sicher, dass jemand da draußen einen Fall finden könnte, in dem sie es tun.

Das Problem, mit dem ich gerade konfrontiert bin, sind Abhängigkeiten (Bibliotheken von Drittanbietern usw.), die meinen Generator (der zu 100% aus ihnen besteht) nicht verwenden, derzeit mit einem Bootstrapper erstellt werden müssen und jedes Mal gebootstrapped werden müssen werden aktualisiert oder geändert usw. Die meisten Generatoren, mit denen ich arbeite, haben die Möglichkeit, in eine Ninja-Konfiguration auszugeben, aber sie sind alle nur für dieses Verzeichnis konfiguriert (dh relativ zu diesem Verzeichnis).

In der Lage zu sein, selektive Neuerstellungen mit ihren Konfigurationen und Diagrammen durchzuführen, wäre enorm. Derzeit kann ich dies nicht tun, da subninja Pfade relativ zum Build-Verzeichnis annimmt.

Evan: Ich habe das so verstanden, dass Sie einen Baum wie diesen erstellen würden:

  subbuild1
  subbuild2

und da Generatoren normalerweise das Platzieren des Build-Verzeichnisses an beliebigen Stellen unterstützen, sollte das Erstellen von Projekt 1 in Subbuild1 und Projekt 2 in Subbuild 2 funktionieren. Dann gibt es eine Toplevel-Ninja-Datei im Builddir, die Qix- zum Erstellen der Unterprojekte antreiben möchte.

Nicht verwandt: Dieses relative -Feature muss auch cwd in sein Argument ändern, wenn irgendwelche Regeln davon abhängen, dass das aktuelle Verzeichnis gleich ihrem Build-Verzeichnis ist (z. B. wenn eine Regel gebaute Artefakte entfernt oder so).