Ninja: Envisagez d'ajouter un deuxième binaire "lourd"

Une idée à moitié cuite serait de faire du code ninja de base une "vraie" bibliothèque, puis de garder le binaire ninja régulier raisonnablement petit et concentré, puis d'ajouter un deuxième binaire quelque part (contrib/monstre ou autre) qui renvoie à la bibliothèque ninja et ajoute toutes ces fonctionnalités. Ce binaire pourrait alors dépendre de toutes sortes de choses.

Ce serait cool. Pour info, nous avons utilisé ninja dans le système de construction bsb sous-jacent pour les projets ReasonML/BuckleScript, en général, nous apprécions les performances de ninja, mais cela semble toujours un peu limité sans mode persistant, je comprends que cela pourrait introduire plus de profondeurs ou le rendre moins multiplateforme après avoir introduit plus de fonctionnalités, mais il est logique d'exporter ninja en tant que bibliothèque

quelque chose d'interface configurable avec une interface de transmission de messages #1210

Ce PR n'ajoute aucune dépendance d'exécution. Qu'est-ce qui vous préoccupe exactement là-bas ?

Parce que s'il s'agit de la taille ou de la maintenabilité du dépôt/distribution Git, avoir un deuxième binaire n'aiderait guère.

Je voudrais avertir que de nombreux projets utilisant Ninja ne s'attendent pas à ce que les utilisateurs aient ninja pré-installé sur leur machine, et un tel projet fournit un script wrapper qui télécharge le binaire Ninja dans l'arborescence du projet lorsque Ninja est nécessaire. Si Ninja n'est plus un exécutable autonome, cela POURRAIT casser ces projets.

par exemple, téléchargez sur https://chrome-infra-packages.appspot.com/dl/gn/gn/mac-amd64/+/latest utilisant Python : (python2) zipfile.ZipFile(io.BytesIO(urllib2.urlopen(url).read())).extract("gn", path="path/bin") , (python3) en remplaçant urllib2 par urllib.request .

Par conséquent, la production d'un exécutable autonome est toujours nécessaire.

Je suis intéressé à faire avancer cela. Mon courant a pensé qu'il fallait donc travailler pour rendre la fonction main() pour ninja très petite et pousser toutes les fonctionnalités actuelles à l'intérieur de ninja.cc dans une limite de bibliothèque. Je vais essayer d'esquisser certaines de ces idées dans le code pour voir si nous pouvons en faire une discussion sur les différents compromis techniques.

Je voudrais avertir que de nombreux projets utilisant Ninja ne s'attendent pas à ce que les utilisateurs aient ninja pré-installé sur leur machine, et un tel projet fournit un script wrapper qui télécharge le binaire Ninja dans l'arborescence du projet lorsque Ninja est nécessaire. Si Ninja n'est plus un exécutable autonome, cela POURRAIT casser ces projets.

par exemple, téléchargez sur https://chrome-infra-packages.appspot.com/dl/gn/gn/mac-amd64/+/latest utilisant Python : (python2) zipfile.ZipFile(io.BytesIO(urllib2.urlopen(url).read())).extract("gn", path="path/bin") , (python3) en remplaçant urllib2 par urllib.request .

Par conséquent, la production d'un exécutable autonome est toujours nécessaire.

Si jamais je vois une arborescence source se transformer en téléchargeant et en exécutant des binaires non signés malveillants, je ne toucherai probablement plus à ce logiciel. Il manque ici une pièce importante du design.

@johan-boule non ce n'est pas le logiciel qui mute lui-même. Un grand projet (par exemple Chromium) peut utiliser un script qui gère les étapes de configuration pour les développeurs, et le script de configuration a cette étape pour récupérer les binaires.

@Leedehai Je rappelais juste que la plupart des développeurs n'acceptent pas de perdre le contrôle de ce qui est téléchargé et exécuté sur leurs machines. Habituellement, cela est rendu acceptable en utilisant un gestionnaire de packages de confiance pour effectuer ce travail. C'est l'élément de la conception du système auquel je faisais allusion.

J'ai créé un PR exploratoire pour cet effort sur https://github.com/ninja-build/ninja/pull/1729. J'ai reçu pas mal de commentaires de jonesmz, mais personne d'autre. Cela peut être compréhensible, le PR est assez long et plutôt sinueux car j'ai compris la structure du ninja. J'ai pensé qu'il serait utile pour moi de résumer ma conception ici pour la discussion.

1. Nous avons besoin d'un système de journalisation qui permette aux clients de la bibliothèque de capturer les messages de journal et de les émettre à leur manière. jonesmz suggère un design similaire à boost, mais limité à quelques points :
   
   
   
   • Plusieurs backends, je peux donc cibler dynamiquement les fichiers journaux, la sortie de la console ou un serveur de journalisation sur le réseau, comme j'en ai envie au moment de l'exécution.
   
   
   • Variables dynamiques capturées avec chaque instruction de journal, qui peuvent inclure le nom des fonctions actuelles, ou l'horodatage actuel, ou ce que vous avez.
   
   
   • Facile à remplacer la fonctionnalité à l'aide de macros. Par exemple, je peux fournir mes propres instructions de journalisation qui personnalisent ce qui est enregistré, en définissant une macro que j'appelle.
   
   
2. Introduction d'un espace de noms ninja. C'est juste agréable quand vous êtes une bibliothèque. Supprimer « utiliser l'espace de noms std » partout où il est toujours utilisé dans les en-têtes.
3. Séparation d'une couche ui qui est chargée d'analyser les arguments de la ligne de commande en diverses structures pour maintenir un comportement configurable. Passez ces structures dans des fonctions configurables pour modifier le comportement.
4. Plus de logique pour "ça va mal, exit maintenant". Donc pas de fonction ExitNow .
5. Création d'une classe Execution pour contenir une grande partie de la logique actuellement dans ninja.cc/NinjaMain . Cela exclut l'analyse des arguments de ligne de commande.
6. Suppression de l'état global - certains sont poussés dans State , qui peuvent être réinitialisés lors de la reconstruction, certains sont poussés dans la nouvelle classe Execution (certaines options, configuration), certains deviennent statiques (debug_flags).
7. Introduction de fichiers d'en-tête publics. Ils vivront dans inc/ninja/*.h . Ceci comprend:
   
   
   
   • build_config.h
   
   
   • depfile_parser_options.h
   
   
   • logger.h
   
   
   • execution.h
   
   
   • ui.h
   
   
   • version.h
   
   
   • win32port.h
   
   

Je vais démarrer une nouvelle branche en réimplémentant mes modifications au-dessus de master en essayant de clarifier mon intention. J'aimerais avoir suffisamment de discussions avec les responsables sur mon approche pour être raisonnablement certain que mon approche est dans la bonne direction.

@nico @jhasse cette direction est-elle acceptable pour vous ? Si non, que préféreriez-vous voir ?

Correction mineure - point 6, rien n'est ajouté aux indicateurs de débogage, mais les éléments statiques en sont supprimés et deviennent des données membres de State ou Execution .

@jhasse ou @scivision vous semblez être les mainteneurs les plus actifs, est-ce un sujet qui vous intéresse ?

Je ne suis qu'un utilisateur Ninja. Je n'ai pas encore ressenti le besoin de ce niveau de réarchitecture de Ninja bien que je puisse au moins comprendre superficiellement les avantages proposés et leur besoin.

Merci d'avoir sonné dans @nico pour obtenir un mainteneur.

Étant donné que personne ne s'est engagé dans cette conversation ou n'a manifesté d'intérêt, il est peut-être d'accord avec vous et n'a pas le temps de le dire.

Je n'en ai pas non plus ressenti le besoin. Je suis très intéressé par #1600 cependant.

D'accord, merci pour la réponse. @jhasse avez-vous un endroit où vous préférez avoir cette discussion ? La conception que je propose permettrait de créer un binaire "lourd". Cela permettrait également de créer un front-end différent, mais cela le ferait assez différemment de ce qui était proposé à l'origine par collincross.

Apporter les modifications architecturales appropriées pour permettre à la base de code Ninja d'être consommée comme une véritable bibliothèque (même liée de manière statique) simplifierait considérablement l'implémentation de #1600 .

Personnellement, je suis très intéressé par la bibliothèque-fication dans un souci d'intégration dans les IDE et autres outils (analyse de fichiers ninja, etc.) sans avoir besoin d'appeler un binaire externe.

Cette question est le bon endroit pour la discussion à ce sujet.

D'accord, donc à ce stade, ce que je recherche est soit :

1 - "Oui, ce plan semble bon à un niveau élevé, continuez et je passerai en revue les détails dès qu'ils seront disponibles pour nous assurer que c'est quelque chose que nous voulons faire pour le ninja."
2 - "Non, je n'aime pas ce plan, je préfère voir quelque chose comme ceci :"

J'aimerais obtenir ceci d'un mainteneur. @jhasse pourriez-vous préciser laquelle de ces deux réponses correspond le mieux à votre opinion ? Je crois que cette conception prend en charge #1600 qui vous intéresse beaucoup. Êtes-vous d'accord ? Souhaitez-vous voir autre chose pour le #1600 ?

3 - "D'après ce que je peux dire, le plan semble bon. Mais pour moi, il y a d'autres problèmes qui m'intéressent davantage et je n'ai pas assez de temps pour examiner les changements."

Je n'ai pas beaucoup réfléchi à la façon dont les changements aideraient #1600. Si je comprends bien, il le remplacerait.

Cela le remplacerait. #1600 a une petite implémentation d'une partie de protobufs intégrée pour permettre la transmission de données à un processus frontal séparé. @nico à un moment donné (en #1210) était contre l'ajout de protobuf à ninja de quelque manière que ce soit. Nico a suggéré de créer deux binaires séparés, un léger qui est le ninja par défaut dans une version et un lourd qui pourrait avoir des choses comme des protobufs et avoir une sortie frontale configurable.

Le but de ma conception ici est de le rendre architecturalement faisable pour le faire. J'essaie de définir une bibliothèque ninja de base et son interface. Cela permettrait au projet ninja de créer un binaire lourd et un binaire léger, tous deux autour de la même bibliothèque. Cela permettrait également aux utilisateurs du projet de se connecter eux-mêmes à la bibliothèque pour personnaliser davantage le comportement.

Au départ, je pensais qu'un PR serait un bon moyen d'avoir une discussion sur la conception globale. Je n'ai eu aucun retour (sauf pour jonesmz, qui était génial). Alors maintenant, j'essaie d'avoir une discussion de haut niveau avant de consacrer plus d'efforts au code.

Du point de vue des responsables, c'est plus simple si je crée tout le code et que vous ne le révisez que lorsqu'il est terminé. De mon point de vue, c'est une dangereuse perte de temps, car la réponse pourrait être "non, je ne veux rien de tel". J'espère que les responsables ninja pourront me rencontrer à mi-chemin et discuter avec moi de ce qu'ils seraient prêts à accepter avant que je consacre plus de temps au code lui-même.

D'accord, j'ai donné cela plusieurs semaines et j'ai essayé de contacter les responsables en utilisant tous les moyens à ma disposition. Je vais considérer cet effort comme « pas assez intéressant pour être pris la peine d'en discuter » du point de vue des responsables.

Je vais ouvrir une discussion avec les responsables du projet splinter pour voir s'ils sont intéressés par quelque chose de similaire.

Si des responsables se présentent et souhaitent commenter définitivement cela, j'apprécierais la clarté.