Notre version de Jam a beaucoup divergé de l'original avec des fonctionnalités supplémentaires. En particulier les "build profiles" qui permettent de compiler différentes configurations facilement. Dans notre cas: jam @nightly-raw pour compiler une image de type "nightly build", jam @release-raw pour compiler une image de type "release" (qui contient plus de choses), etc. Un profil permet de customiser pas mal de choses au moment de la compilation.
Dans d'autres projets ces profils pourraient être utilisés pour compiler le même exécutable en release ou en debug, par exemple.
Il faudrait donc reporter ces changements dans Boost.Jam, ce qui est compliqué à faire directement parce qu'ils ont énormément retravaillé l'architecture du code (je le sais parce que j'ai porté des patchs dans l'autre sens, par exemple pour pouvoir générer un compile_commands.json).
C'est un exemple d'incompatibilité, mais il y en a plusieurs autres y compris sur la syntaxe du langage Jam. Ham prévoit à terme de savoir lire les Jamfiles des différentes variantes existantes (Haiku, Boost, Perforce original, et peut-être Freetype Jam).
La deuxième raison:
Ham n'est pas seulement un exécutable, il y a une bibliothèque partagée qui pourrait par exemple être utilisée dans un IDE. Ainsi l'IDE n'aurait pas besoin d'un fichier "projet" séparé mais pourrait utiliser (et modifier) directement les Jamfiles et lancer la compilation sans devoir passer par le lancement d'un outil en ligne de commande. Ce qui permettrait par exemple de recompiler directement juste les fichiers concernés quand on enregistre un fichier .cpp ou .h, en tâche de fond. Sans avoir à re-lire et parser tous les Jamfiles à chaque fois comme quand on lance l'outil en ligne de commande. Ou encore d'avoir un outil en tâche de fond qui fait ça même sans IDE.
Troisième raison:
La coordination entre plusieurs projets (Boost et Haiku par exemple) est souvent compliquée. Ils apprécierait pas forcément qu'on ajoute tous nos trucs dans leur version. Et si le résultat c'est remplacer un fork de Jam par un fork de Boost.Jam, on aura pas gagné grand chose.
[^] # Re: ♪ A Ham Jam Jam , compile compile compile, A Ham Jam Jam ♪
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a (presque) 21 ans. Évalué à 10.
Première raison:
Notre version de Jam a beaucoup divergé de l'original avec des fonctionnalités supplémentaires. En particulier les "build profiles" qui permettent de compiler différentes configurations facilement. Dans notre cas:
jam @nightly-rawpour compiler une image de type "nightly build",jam @release-rawpour compiler une image de type "release" (qui contient plus de choses), etc. Un profil permet de customiser pas mal de choses au moment de la compilation.Dans d'autres projets ces profils pourraient être utilisés pour compiler le même exécutable en release ou en debug, par exemple.
Il faudrait donc reporter ces changements dans Boost.Jam, ce qui est compliqué à faire directement parce qu'ils ont énormément retravaillé l'architecture du code (je le sais parce que j'ai porté des patchs dans l'autre sens, par exemple pour pouvoir générer un compile_commands.json).
C'est un exemple d'incompatibilité, mais il y en a plusieurs autres y compris sur la syntaxe du langage Jam. Ham prévoit à terme de savoir lire les Jamfiles des différentes variantes existantes (Haiku, Boost, Perforce original, et peut-être Freetype Jam).
La deuxième raison:
Ham n'est pas seulement un exécutable, il y a une bibliothèque partagée qui pourrait par exemple être utilisée dans un IDE. Ainsi l'IDE n'aurait pas besoin d'un fichier "projet" séparé mais pourrait utiliser (et modifier) directement les Jamfiles et lancer la compilation sans devoir passer par le lancement d'un outil en ligne de commande. Ce qui permettrait par exemple de recompiler directement juste les fichiers concernés quand on enregistre un fichier .cpp ou .h, en tâche de fond. Sans avoir à re-lire et parser tous les Jamfiles à chaque fois comme quand on lance l'outil en ligne de commande. Ou encore d'avoir un outil en tâche de fond qui fait ça même sans IDE.
Troisième raison:
La coordination entre plusieurs projets (Boost et Haiku par exemple) est souvent compliquée. Ils apprécierait pas forcément qu'on ajoute tous nos trucs dans leur version. Et si le résultat c'est remplacer un fork de Jam par un fork de Boost.Jam, on aura pas gagné grand chose.