Ninja: Unterstützen Sie die Einstellung der Ausführlichkeit durch die Umgebung

Ich denke, in solchen Fällen können Sie ein Shell-Skript erstellen, um Ihre Umgebungsvariablen zu befolgen. Ansonsten kann ich mir äquivalente Umgebungen vorstellen, in denen jemand möchte, dass VERBOSE=1 die Ausführlichkeit eines anderen Programms als Ninja steuert.

Ich denke, in solchen Fällen können Sie ein Shell-Skript erstellen, um Ihre Umgebungsvariablen zu befolgen.

Diese Umgebungsvariablen sind für Ninja, also wie würden sie befolgt, wenn Ninja sie nicht erkennt?

Außerdem ist es nicht immer machbar oder sinnvoll, die Befehlszeile von Tools in Skripten zu ändern, da es viel zu viele gibt. Was Sie vorschlagen, ist, dass jedes Skript eine einzigartige Methode zur Anpassung der an den Befehl übergebenen Flags anwendet, was ebenfalls unvernünftig ist.

Ich habe die anderen PRs und Probleme im Zusammenhang mit dieser Situation gelesen und finde keine der Antworten sehr gut durchdacht. In jedem Fall wird einfach davon ausgegangen, dass der Benutzer die direkte Kontrolle darüber hat, wo und wie ninja ausgeführt wird oder sogar in der Lage ist, realistisch etwas dagegen zu tun, insbesondere wenn Konfigurationssysteme ninja.build Skripte generieren als Teil der Pipeline.

Diese Umgebungsvariablen sind für Ninja, also wie würden sie befolgt, wenn Ninja sie nicht erkennt?

Das Skript würde sie erkennen und zB -v an Ninja weitergeben.

Wie ich vorhergesagt habe, erwarten Sie also, dass jedes Skript oder sogar skriptähnliche Ding seine eigene Logik codiert, um Optionen an Ninja weiterzugeben. Das ist überhaupt nicht vernünftig.

Nein, Sie brauchen dafür nur ein Skript, das Sie ninja und es in Ihre PATH vor der echten ausführbaren Ninja-Datei einfügen.

Ich dachte, das wäre schon in den anderen zahlreichen Problemberichten behandelt worden? Das ist auch nicht vernünftig, da es jetzt beginnt, Reproduzierbarkeits-Build-Pipelines zu beeinflussen, in denen Umgebungen nachverfolgt werden können. Es geht auch davon aus, dass die Leute die Möglichkeit haben, das zu tun, was Sie vorschlagen (denken Sie an sichere PATH ).

Das ist auch nicht vernünftig, da es jetzt beginnt, Reproduzierbarkeits-Build-Pipelines zu beeinflussen, in denen Umgebungen nachverfolgt werden können.

Du hättest dein Skript immer da, dann kannst du VERBOSE genau so verfolgen, als würde Ninja es selbst handhaben.

denke sicher PATH

Was meinst du damit?

Ich bin nicht an VERBOSE interessiert, ich denke, die anderen Vorschläge zum Freilegen der Flags über NINJAFLAGS sind angemessener als in vielen anderen Ausgaben zu diesem Thema.

Auch dies ist eine unvernünftige Anforderung, wenn Sie Hunderte von Paketen verwalten, von denen einige cmake verwenden, um Ninja-Build-Skripts zu generieren. Das Erstellen eines unnötigen Wrappers als Abhängigkeit ist übermäßig aufwendig, wenn traditionelle Systeme wie make (mit richtig generierten oder geschriebenen Makefile s) weiterhin nicht nur die De-facto-Umgebungen wie CFLAGS ehren CXXFLAGS , LDFLAGS , etc. aber auch MAKEFLAGS wo viele von uns etwas wie -j$(nproc) einstellen würden.

Dies führt wiederum zur Vorstellung eines sicheren Pfads; Systeme wie sudo und build/CI-Skripte setzen PATH auf einen bekannten guten Standard, um jede potenzielle Verschmutzung des Builds zu vermeiden, die normalerweise auch von einem sauberen Chroot untermauert wird.

Einige von ihnen verwenden cmake, um Ninja-Build-Skripte zu generieren.

Ich sehe nicht, wie das etwas ändert?

Dies führt wiederum zur Vorstellung eines sicheren Pfads; Systeme wie sudo und build/CI-Skripte setzen PATH auf einen bekannten guten Standard, um eine potenzielle Verschmutzung des Builds zu vermeiden, die normalerweise auch durch eine saubere Chroot untermauert wird.

In diesem Fall können Sie die Änderung von PATH vermeiden, indem Sie die Ninja-Binärdatei umbenennen und das Skript an ihre Stelle setzen.

Und herum gehen wir

In diesem Fall können Sie die Änderung von PATH vermeiden, indem Sie die Ninja-Binärdatei umbenennen und das Skript an ihrer Stelle einfügen.

Dies vorzuschlagen ist sehr unangemessen.

Benutzer sollten niemals mit Binärdateien auf Systemebene herumspielen.

Für ein Mehrbenutzersystem ist es nicht angemessen, die Binärdatei auf Systemebene umzubenennen und durch ein Skript zu ersetzen.

Ich sage es noch einmal fürs Protokoll: Ich betreue ein maßgeschneidertes Buildsystem für ein C++-Entwicklungsteam, es kompiliert mehrere Millionen Zeilen C++-Code. Früher hat es viele Dinge direkt erledigt, aber jetzt generiert es Ninja-Dateien und die Dinge sind glücklich. Ich habe also ein paar Anhaltspunkte, die ich aneinanderreiben muss, wenn ich darüber spreche.

Was ich möchte: Damit die Ninja-Binärdatei eine einzelne Umgebungsvariable erkennt, die verschiedene Standardeinstellungen festlegt, einschließlich Ausführlichkeit und dergleichen.

Was ich akzeptieren kann: Ninja reagiert auf mehrere Umgebungsvariablen.

Was nicht akzeptabel ist: Sie müssen ein Wrapper-Skript schreiben.

Warum das nicht akzeptabel ist: Bei der Bereitstellung unter Windows würde das gut funktionieren, nehme ich an. Unter Linux ist dies jedoch nicht akzeptabel, da wir uns auf das Ninja-Paket des Systems verlassen, um die Funktionalität bereitzustellen. Bei der Bereitstellung auf Linux-Systemen lautet Ihr Vorschlag hier "Oh, benennen Sie einfach das Ninja-Paket auf Systemebene um und ersetzen Sie es durch ein Skript", schreit es nach Sicherheitsproblemen und Wartungsproblemen. Unter anderem muss ich jetzt jedes Mal, wenn das Ninja-Paket vom Paketmanager des Systems aktualisiert wird, das System babysitten.

Das Hinzufügen dieser Funktion zum Programm ist nicht riskant. Ninjas Aufgabe ist es nicht, Benutzer vor sich selbst zu schützen. Wenn ein Benutzer es irgendwie schafft, es zu vermasseln, liegt das an ihm.

Die Wahrscheinlichkeit, dass Ninja ein solches Feature um mehr als ein paar Mikrosekunden verlangsamt, ist so gering, dass es nicht existiert, aber Ihr Vorschlag ist, dass wir ein Wrapper-Skript verwenden, bei dem jedes Mal ein Skriptinterpreter ausgeführt wird Ninja wird gestartet, was bei weitem mehr Overhead bedeutet als ein paar Zeichenfolgenvergleiche in einer bereits ausgeführten Binärdatei.

Bei der Bereitstellung auf Linux-Systemen lautet Ihr Vorschlag hier "Oh, benennen Sie einfach das Ninja-Paket auf Systemebene um und ersetzen Sie es durch ein Skript", schreit es nach Sicherheitsproblemen und Wartungsproblemen.

Nein, bei der Bereitstellung unter Linux würde ich vorschlagen, das Skript in /usr/local/bin .

Ich habe dieses Verzeichnis anscheinend nicht auf meinem Linux-Rechner.

Ich kann im Dateisystemhierarchie-Standard http://www.pathname.com/fhs/pub/fhs-2.3.pdf keinen Verweis darauf finden

Ich habe aber im FHS einen Hinweis auf /usr/local/sbin gefunden, vielleicht meintest du das? Es scheint seltsam, dafür einen "sbin" -Ordner zu verwenden.

Vermutlich soll /usr/local/bin im PATH vor /usr/bin und anderen stehen.

Das haben Sie jedoch nicht gesagt. Du hast das gesagt:

In diesem Fall können Sie die Änderung von PATH vermeiden, indem Sie die Ninja-Binärdatei umbenennen und das Skript an ihrer Stelle einfügen.

Und das ist ein schlechter Vorschlag, gespickt mit Sicherheits- und laufenden Wartungsproblemen.

Es ist besser, ein Skript in ein systemweites Verzeichnis zu legen, das immer vor allem anderen enthalten ist, als die Binärdatei umzubenennen und ein Skript an ihre Stelle zu kopieren.

Nichtsdestotrotz habe ich noch keine Erklärung dafür gesehen, warum wir dies nicht nur in Ninja selbst aufnehmen, das war in sich selbst konsistent, verursachte keinen zusätzlichen Aufwand durch das Aufrufen eines Skripts und / oder "jeder muss sein schreiben" eigenes Skript jetzt", und wies auf die Richtlinien für das Ninja-Projekt hin, die hier auf github dokumentiert sind.

Die unabhängige Ninja-Build-Sprachreimplementierung https://github.com/michaelforney/samurai unterstützt dies über die Umgebungsvariable SAMUFLAGS. Verwenden Sie samu einfach überall dort, wo Sie sonst ninja verwenden würden, oder installieren Sie samu als Ihr System /usr/bin/ninja (einige Linux-Distributionen haben Optionen, diese konkurrierende Implementierung als Standard oder nur Ninja zu installieren).