Erfolg und Misserfolg von Ninja (2020)

 (neugierig.org)
2 Punkte von GN⁺ 2024-11-30 | 1 Kommentare | Auf WhatsApp teilen

  • Erfolge und Misserfolge von Ninja

    • Vor etwa 9 Jahren veröffentlichte der Autor Ninja, ein Make ähnliches Build-System. Anfangs war ihm das peinlich, heute wird es jedoch weit verbreitet genutzt.
    • Zu den wichtigsten Projekten, die Ninja verwenden, gehören Chrome, Android und das Meson-Projekt.
    • Ninja ist das erfolgreichste Open-Source-Projekt des Autors: Es wurde 2011 veröffentlicht, 2014 übergab er die Eigentümerschaft, und inzwischen wurde es an den dritten Maintainer weitergereicht.
    • Er lernte, dass in der Programmierung Architektur wichtiger ist als das Schreiben von Code und dass soziale Fragen noch wichtiger sind als Architektur.

  • Technische Details

    • Ninja ist ein einfaches System, das gemäß den vorgegebenen Anforderungen Befehle ausführt.
    • Ninja verarbeitet eine ninja.build-Datei, prüft die Änderungszeiten von Dateien und führt die nötigen Befehle parallel aus.
    • Im Vergleich zu Make hat Ninja weniger Funktionen in der Eingabe-Build-Sprache und konzentriert sich auf schnelle Ausführung.
    • Ninja optimiert Pfadvergleiche, indem Eingabedateipfade auf Objekte im Speicher abgebildet werden.

  • Architektur-Notizen

    • Die Graphdarstellung von Ninja verwendet einen bipartiten Graphen zwischen Dateien und Befehlen, um die Build-Struktur besser abzubilden.
    • Zur Verarbeitung von C-Header-Abhängigkeiten werden zusätzliche Abhängigkeitsdaten verwendet.
    • Ninja ist kein persistenter Daemon-Prozess, sondern beginnt bei jedem Lauf wieder von vorn.
    • Da der Kernel den Dateistatus bereits zwischenspeichert, ist es im User Space kaum nötig, ihn noch einmal zu cachen.
    • Ninja wurde auf Basis des Chrome-Builds entworfen und stößt in sehr großen Projekten auf Skalierungsprobleme.

  • Die Metapher des „Assemblers“

    • Ninja implementiert nicht die Funktionen verschiedener Build-Systeme, sondern nur den Aktionsgraphen, sodass Nutzer andere Generatorprogramme wählen können.
    • Dieses Design macht Ninja schnell und flexibel.

  • Die Bedeutung von Standardwerten

    • Ninja führt Befehle standardmäßig parallel aus und ermöglicht dadurch sicherere parallele Builds als Make.

  • Geschwindigkeit

    • Ninja konzentriert sich auf die Performance inkrementeller Builds in großen Codebasen, was die Zufriedenheit der Nutzer stark beeinflusst.
    • Ninja verbraucht wenig CPU und verbessert dadurch auch die Gesamtleistung von Builds.

  • CMake

    • Ninja ist gut in CMake integriert und wird dank dieser Integration für die Arbeit an LLVM verwendet.

  • Windows-Unterstützung

    • Ninja funktioniert auch unter Windows, und viele frühe Nutzer waren Windows-Anwender.

  • Verwandte Arbeiten

    • Das Design von Ninja wurde von Googles Build-System blaze/bazel inspiriert.

  • Open-Source-Wartung

    • Open-Source-Wartung macht keinen Spaß, und es gab viele Forderungen und viel Kritik von Nutzern.
    • Der Autor wollte mit Software Eindruck auf andere Hacker-Kollegen machen.

  • Abschließender Dank

    • Er spricht den Maintainern und Beitragenden von Ninja seinen Dank aus.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-30
Hacker-News-Kommentare

  • Es gibt die Ansicht, dass bei der Programmierung die Architektur wichtiger ist als das Schreiben von Code und dass soziale Fragen noch wichtiger sind als die Architektur.

    • Das sei eine gute Formulierung eines Gedankens, den man schon lange im Kopf gehabt habe.

  • Im Build-System von Android spielt Ninja eine große Rolle.

    • Anfangs wurden makefiles verwendet, später wurde es mit einem benutzerdefinierten deklarativen Build-System namens soong komplexer.
    • Google entwickelte kati, das Makefiles in Ninja-Build-Dateien umwandelt.
    • Die Umstellung auf Ninja dauert zwar, läuft danach aber schnell.

  • Es gibt die Meinung, dass Google Forschung zu Latenz durchgeführt habe, und den Wunsch, dass diese Forschung veröffentlicht wird.

  • Bei der Verwendung von CMake werde Ninja wegen der C++20-Module weiterhin noch eine Zeit lang gebraucht.

  • Man sei von Ninja auf Samurai umgestiegen, und es habe sich in jeder Hinsicht verbessert.

    • Ein Build-System sollte nach dieser Ansicht die Hashes aller Eingaben berechnen und prüfen, ob sie in der Registry vorhanden sind.

  • Es gibt die Ansicht, dass zwischen Korrektheit, Komfort und Performance Kompromisse nötig sind und diese bewusst gewählt werden sollten.

    • Ein Tool, das zugunsten des Komforts auf Korrektheit verzichtet, könne ein genaueres Ökosystem schaffen.

  • Man habe Erfahrung mit Build-Systemen, und Ninja sei klein genug, um es in einer bevorzugten Programmiersprache implementieren zu können.

    • Man frage sich, ob es ein schrittweises Tutorial zum Erstellen eines eigenen Build-Systems gibt.

  • Man finde den Namen Ninja gut und meine, dass es Möglichkeiten gebe, es noch schneller zu machen.

    • Es wird erklärt, dass das Tool absichtlich keinen Zustand früherer Ausführungen beibehält.