Les succès et les échecs de Ninja (2020)

• Les succès et les échecs de Ninja

  • Il y a environ 9 ans, l’auteur a présenté Ninja, un système de build similaire à Make. Au début, c’était un peu embarrassant, mais aujourd’hui il est largement utilisé.
  • Parmi les principaux projets qui utilisent Ninja figurent Chrome, Android et le projet Meson.
  • Ninja est le projet open source le plus réussi de l’auteur : publié en 2011, il en a transmis la propriété en 2014, et il est désormais entre les mains d’un troisième mainteneur.
  • Il a appris qu’en programmation, l’architecture est plus importante que l’écriture du code, et que les problèmes sociaux sont encore plus importants que l’architecture.

• Détails techniques

  • Ninja est un système simple qui exécute des commandes selon des exigences données.
  • Ninja lit un fichier ninja.build, vérifie l’horodatage de modification des fichiers et exécute en parallèle les commandes nécessaires.
  • Par rapport à Make, Ninja offre moins de fonctionnalités dans son langage de build d’entrée et met l’accent sur une exécution rapide.
  • Ninja optimise la comparaison des chemins en associant les chemins de fichiers à des objets en mémoire.

• Notes d’architecture

  • La représentation du graphe de Ninja utilise un graphe biparti entre fichiers et commandes, ce qui capture mieux la structure du build.
  • Des données de dépendances supplémentaires sont utilisées pour gérer les dépendances des en-têtes C.
  • Ninja n’est pas un processus démon persistant et recommence son travail depuis le début à chaque exécution.
  • L’état des fichiers étant déjà mis en cache par le noyau, il est rarement nécessaire de le mettre de nouveau en cache en espace utilisateur.
  • Ninja a été conçu à partir du build de Chrome et rencontre des problèmes de passage à l’échelle sur les très grands projets.

• La métaphore de « l’assembleur »

  • Au lieu d’implémenter les fonctionnalités de divers systèmes de build, Ninja n’implémente que le graphe d’actions et laisse l’utilisateur choisir d’autres programmes générateurs.
  • Cette conception rend Ninja rapide et flexible.

• L’importance des valeurs par défaut

  • Ninja exécute les commandes en parallèle par défaut, ce qui permet des builds parallèles plus sûrs qu’avec Make.

• Vitesse

  • Ninja met l’accent sur les performances des builds incrémentaux dans les grandes bases de code, ce qui a un fort impact sur la satisfaction des utilisateurs.
  • Ninja utilise moins de CPU, ce qui améliore aussi les performances globales des builds.

• CMake

  • Ninja s’intègre bien à CMake, et cette intégration lui a permis d’être utilisé pour le travail sur LLVM.

• Support de Windows

  • Ninja fonctionne aussi sous Windows, et nombre de ses premiers utilisateurs étaient sur Windows.

• Travaux connexes

  • La conception de Ninja s’est inspirée de blaze/bazel, le système de build de Google.

• Maintenance open source

  • La maintenance open source n’est pas agréable, et il y a eu beaucoup de demandes et de critiques de la part des utilisateurs.
  • L’auteur voulait impressionner ses collègues hackers à travers son logiciel.

• Remerciements finaux

  • L’auteur adresse ses remerciements aux mainteneurs et contributeurs de Ninja.

[GN⁺]

Commentaires Hacker News

• Certains estiment qu’en programmation, l’architecture est plus importante que l’écriture du code, et que les enjeux sociaux sont encore plus importants que l’architecture

  • Cela exprimerait très bien une idée qu’ils avaient en tête depuis longtemps

• Ninja joue un rôle important dans le système de build d’Android

  • Au début, des makefiles étaient utilisés, puis cela s’est complexifié avec soong, un système de build déclaratif personnalisé
  • Google a développé kati, qui convertit les Makefiles en fichiers de build Ninja
  • La transition vers Ninja prend du temps, mais une fois effectuée, cela fonctionne rapidement

• Certains indiquent que Google a mené des recherches sur la latence et espèrent que ces travaux seront rendus publics

• Certains pensent que Ninja restera utilisé pendant un certain temps, car il est nécessaire pour les modules C++20 avec CMake

• Certains sont passés de Ninja à Samurai et disent que tout s’est amélioré

  • Ils estiment qu’un système de build doit calculer le hash de toutes les entrées et vérifier leur présence dans un registre

• Certains estiment qu’un compromis est nécessaire entre exactitude, praticité et performances, et qu’il faut le choisir de manière délibérée

  • Un outil qui sacrifie l’exactitude au profit de la praticité peut, selon eux, créer un écosystème plus exact

• Certains disent avoir de l’expérience avec les systèmes de build et que Ninja est suffisamment petit pour être implémenté dans son langage de programmation préféré

  • Ils se demandent s’il existe un tutoriel étape par étape pour créer son propre système de build

• Certains trouvent que le nom de Ninja est bon et disent qu’il existe un moyen de le rendre plus rapide

  • Ils expliquent que l’outil ne conserve pas délibérément l’état de l’exécution précédente