Dans le pire des cas on va en détruire un (Haiku Jam) pour le remplacer par un autre (Ham). Dans le meilleur des cas, on va en détruire deux (Haiku Jam et Boost Jam) pour les remplacer tous les deux par Ham.
En fait tout cela est assez neutre puisqu'on ne crée pas de nouveaux fichiers de build, on crée un nouvel outil qui utilise les fichiers déjà existants. Qui sont d'ailleurs loin d'être parfaits dans Jam, mais je pense que ça va permettre de travailler sur des aspects intéressants du problème (intégration dans les IDE, meilleur suivi des dépendances, rapidité de parsing des fichiers) en sautant les étapes "réinvention de la roue" de la conception d'un nouveau langage de build.
Peut-être que d'autres outils devraient faire ça? Est-ce qu'on adopterait plus rapidement un outil qui fait "tout comme CMake mais deux fois plus vite" qu'un outil "il faut réécrire tous les scripts de build mais ça va trois fois plus vite"?
Utiliser les outils existants (en tout cas ceux qui existaient en 2001, j'ai pas re-vérifié depuis) pour Haiku c'est compliqué. Pour un build de Haiku il y a 3 compilateurs qui entrent en jeu: un pour compiler des trucs sur le système hôte, et un gcc2 et un gcc11 pour compiler sur la cible. Et au début il nous fallait un outil qui fonctionnait sous BeOS. Sans compter les petits morceaux compilés en assembleur, les astuces pour générer un bootloader EFI valide (qui est en gros un .exe pour Windows mais pas tout à fait), des images de DVD contanant plusieurs systèmes de fichiers, ...
On a un moment réfléchi à tenter d'utiliser CMake mais il ne semble pas vraiment assez flexible pour ça. Je crois qu'à l'époque on en avait discuté avec ReactOS, ils utilisent CMake, mais en fait ils avaient une version patchée pour pouvoir faire tout ce qu'ils voulaient.
Maintenant, si un développeur de Boost.Jam se mettait en tête d'intégrer tout ce dont on a besoin dans Boost.Jam, on serait très content de leur refiler la maintenance du système de build et de plus avoir besoin de le faire nous-même. Mais jusqu'à maintenant, ce n'est pas arrivé.
[^] # 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.
Dans le pire des cas on va en détruire un (Haiku Jam) pour le remplacer par un autre (Ham). Dans le meilleur des cas, on va en détruire deux (Haiku Jam et Boost Jam) pour les remplacer tous les deux par Ham.
En fait tout cela est assez neutre puisqu'on ne crée pas de nouveaux fichiers de build, on crée un nouvel outil qui utilise les fichiers déjà existants. Qui sont d'ailleurs loin d'être parfaits dans Jam, mais je pense que ça va permettre de travailler sur des aspects intéressants du problème (intégration dans les IDE, meilleur suivi des dépendances, rapidité de parsing des fichiers) en sautant les étapes "réinvention de la roue" de la conception d'un nouveau langage de build.
Peut-être que d'autres outils devraient faire ça? Est-ce qu'on adopterait plus rapidement un outil qui fait "tout comme CMake mais deux fois plus vite" qu'un outil "il faut réécrire tous les scripts de build mais ça va trois fois plus vite"?
Utiliser les outils existants (en tout cas ceux qui existaient en 2001, j'ai pas re-vérifié depuis) pour Haiku c'est compliqué. Pour un build de Haiku il y a 3 compilateurs qui entrent en jeu: un pour compiler des trucs sur le système hôte, et un gcc2 et un gcc11 pour compiler sur la cible. Et au début il nous fallait un outil qui fonctionnait sous BeOS. Sans compter les petits morceaux compilés en assembleur, les astuces pour générer un bootloader EFI valide (qui est en gros un .exe pour Windows mais pas tout à fait), des images de DVD contanant plusieurs systèmes de fichiers, ...
On a un moment réfléchi à tenter d'utiliser CMake mais il ne semble pas vraiment assez flexible pour ça. Je crois qu'à l'époque on en avait discuté avec ReactOS, ils utilisent CMake, mais en fait ils avaient une version patchée pour pouvoir faire tout ce qu'ils voulaient.
Maintenant, si un développeur de Boost.Jam se mettait en tête d'intégrer tout ce dont on a besoin dans Boost.Jam, on serait très content de leur refiler la maintenance du système de build et de plus avoir besoin de le faire nous-même. Mais jusqu'à maintenant, ce n'est pas arrivé.