Sur une nouvelle branche "experimental" du repository, hier soir et ce matin, j'ai implémenté le build depuis un clone du repository en quatre commandes:
[code]$ cd trunk/tigcc-linux/scripts
$ ./updatesrc
$ cd ../gcc4ti-0.96b11
$ scripts/Install[/code]
(et encore, on doit pouvoir regrouper les deux premières puis modifier la troisième)
Ce qui nécessitait une config manuelle, et plusieurs minutes de calcul, était la regénération de la doc et des include avec le système spécifique hérité. J'ai donc supprimé cette étape, en committant 3000+ fichiers générés. Le message de commit indique l'avantage (build facilité pour les utilisateurs) et le défaut (pollution encore plus élevée des diffs quand on déplace des fichiers de doc)... mais les très rares personnes qui lisent des diffs n'ont qu'à skipper les modifs pas intéressantes sur les fichiers auto-générés, voilà.
Par là-même, l'utilité d'une amélioration du système de build (passage de ce système de scripts à un système standard) a diminué. Le seul vrai avantage restant que je vois serait un build incrémental. Mais sachant que ce qui prend le plus de temps est le build de gcc+binutils, et que ce sont deux parties qui changent très peu... un truc facile serait de s'inspirer d'une pratique répandue dans les "configure": dans scripts/Install, poser à l'utilisateur une cinquième question "Do you want to rebuild gcc and binutils (y/n, default y) ?".
Un soft dont le packaging est basé sur un enchaînement non documenté de scripts qui nécessitent une pré-configuration manuelle non documentée est un moyen possible pour des mainteneurs de se rendre indispensables sur le court et moyen terme; pour les utilisateurs et sur le long terme, il n'est pas garanti que ce soit souhaitable.