Ninja: Les chemins de sous-ninja relatifs ne se résolvent pas

Tous les chemins sont relatifs au répertoire de construction, pas au fichier contenant la ligne subninja.

Cela n'a aucun sens, cependant. Cela signifie que les générateurs vont devoir _tous_ implémenter un moyen d'ajouter un préfixe aux fichiers, ce qui signifie changer les commandes du répertoire de travail exécutées (ce qui peut changer l'intention d'origine de la configuration de construction en fonction de la façon dont le générateur/les commandes s'exécutent).

Quels sont alors les cas d'utilisation contrastés pour subninja vs include ?

Un sous-ninja avec des chemins relatifs au fichier de construction serait utile dans la mesure où les dépendances configurées pour s'exécuter dans leur propre répertoire peuvent le faire sans avoir à modifier leurs chemins, mais peuvent toujours contribuer au graphique de dépendance de la configuration ninja parent.

La fonctionnalité include ne serait pas modifiée et agirait exactement comme les sous-ninjas autres que les noms de règles de fait seraient désormais dans un espace de noms combiné (selon # 921). Actuellement, subninja et include réalisent essentiellement la même chose à part les variables de portée et les noms de règles...

L'idée est que le générateur génère tous les fichiers .ninja, afin qu'ils puissent écrire des chemins relatifs au répertoire de construction. C'est une idée intéressante de combiner des fichiers ninja générés par différents générateurs (on dirait que c'est ce que vous voulez faire ?), mais ce n'est pas quelque chose qui est pris en charge pour le moment.

Correct, la différence entre subninja et include est que le premier ajoute une portée et le second non. Le cas d'utilisation pour cela est que le ninja de haut niveau peut définir des règles de construction communes telles que cc qui font référence à des variables telles que cflags , et chaque sous-ninja peut définir cflags sur ce qui est approprié pour cette cible, et là peuvent y avoir des actions ponctuelles. Pour voir un exemple, vous pouvez exécuter python misc/write_fake_manifests.py /tmp/foo` pour écrire un tas de fichiers .ninja dans /tmp/foo qui utilisent ce modèle.

Cela a du sens, même si je ne vois toujours pas beaucoup d'avantages (autres que la portée).

C'est une idée intéressante de combiner des fichiers ninja générés par différents générateurs (on dirait que c'est ce que vous voulez faire ?)

Exactement. Pouvoir inclure Ninja lui-même en tant que sous-module pour mon générateur, puis un autre projet CMake (qui est configuré pour générer des fichiers de construction Ninja), puis générer les fichiers de configuration Ninja pour les deux et les inclure en tant que subninja s dans le fichier build.ninja _mon_ projet afin de pouvoir les construire comme s'ils étaient seuls, tout en permettant à mon projet d'utiliser leurs sorties (et donc leurs graphes de dépendance) afin de construire l'ensemble du projet en une seule fois .

Si ça a du sens. Le cas d'utilisation immédiat que je vois avec mon générateur en particulier est qu'il emprunte quelques concepts à Tup (dont l'IIRC a influencé certaines décisions de conception au sein de Ninja lui-même) en ce sens que je peux inclure N sous-projets, tous avec leur propre build.ninja fichiers, puis puisez dans leurs graphiques pour me permettre de construire automatiquement un graphique de dépendance beaucoup plus grand.

Personnellement, je pense que cela rendrait subninja beaucoup plus utile, bien que je puisse voir que c'est un changement potentiellement radical. Cependant, je ne vois pas de moyen de contourner cela à moins que 1) je modifie les fichiers build.ninja des dépendances avec un correctif ou 2) sacrifie la capacité d'exploiter les graphiques de dépendance des dépendances.

Les pensées?

Que diriez-vous:

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

et un relative absent est par défaut ./ . Cela le rendrait incassable mais donnerait toujours la fonctionnalité si un générateur le souhaite.

Ou, en suivant les étapes d'autres constructions Ninja, peut-être

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

Supposons que vous ayez un projet sur .../foo et qu'il ait une barre de sous-répertoires, et que Ninja ait la logique de chemin relatif que vous suggérez.

Si votre système de construction veut écrire toutes les sorties de construction dans /foo/obj, un sous-ninja dans /foo/bar qui utilise des chemins relatifs au répertoire devrait savoir écrire sa sortie dans ../obj/bar, car c'est le chemin vers le fichier de ce sous-répertoire. Ainsi, tout ce qui génère vos fichiers build.ninja doit déjà être conscient de la hiérarchie globale des chemins, auquel cas rendre tous les chemins relatifs est effectivement le même problème que d'ajouter un bar/ aux chemins du répertoire bar/ .

Peut-être qu'il y a suffisamment de personnes qui écrivent la sortie de construction dans leurs répertoires source pour que ce qui précède n'ait pas d'importance, cependant. J'entends surtout des gens qui veulent une séparation encore plus forte - comme les gens qui ont envoyé des correctifs à Ninja pour faire en sorte qu'ils puissent construire Ninja avec la sortie de construction dans un répertoire totalement indépendant.

Je ne suis pas sûr de comprendre. Les sous-ninjas, dans le cas d'utilisation que j'ai décrit en particulier, ne connaissent normalement pas la structure du ninja parent (du moins, n'ont pas besoin de le savoir). Je suis sûr que quelqu'un là-bas pourrait trouver un cas où ils le font, cependant.

Le problème auquel je suis confronté en ce moment est que les dépendances (bibliothèques tierces, etc.) qui n'utilisent pas mon générateur (qui en est à 100%) doivent actuellement être construites à l'aide d'un bootstrapper, et doivent être bootstrapées à chaque fois qu'elles sont mis à jour ou modifiés, etc. La plupart des générateurs avec lesquels je travaille ont les options de sortie vers une configuration ninja, mais ils sont tous configurés pour ce répertoire seul (c'est-à-dire par rapport à ce répertoire).

Pouvoir effectuer des reconstructions sélectives en utilisant leurs configurations et leurs graphiques serait énorme. Actuellement, je ne peux pas le faire car subninja suppose des chemins relatifs au répertoire de construction.

Evan : La façon dont j'ai compris cela, c'est que vous créeriez un arbre comme celui-ci :

  subbuild1
  subbuild2

et puisque les générateurs prennent généralement en charge le placement du répertoire de construction à des endroits arbitraires, la construction du projet 1 dans la sous-construction 1 et du projet 2 dans la sous-construction 2 devrait fonctionner. Ensuite, il y a un fichier ninja de niveau supérieur dans builddir que Qix veut piloter pour construire les sous-projets.

Sans rapport : cette fonctionnalité relative doit également remplacer le cwd par son argument si des règles dépendent du fait que le répertoire actuel est égal à leur répertoire de construction (par exemple, si une règle supprime les artefacts construits ou quelque chose du genre).