29

À vrai dire, peut importe l'un ou l'autre des forks

libti*/gfm/tilp sont maintenus et reçoivent des contributions externes, et comportent des dizaines de bugfixes et features que leurs inutiles forks hostiles, non maintenus depuis bientôt deux ans, sans contributions externes, ne comportent pas wink
mais j'ai envie de dire, si je compile, autant faire un dépôt, non ?

Les dépôts non officiels sont peu utiles, et il est impossible de packager GCC4TI dans un repo officiel:
* compiler et packager GCC4TI est moins difficile que compiler et packager TIGCC, mais ce processus reste moins facile qu'il devrait l'être, malgré les améliorations des scripts dans GCC4TI;
* l'arborescence de fichiers historique de TIGCC/GCC4TI viole plusieurs guidelines de packaging. Un soft bien élevé ne nécessite pas la définition de variables d'environnement ($TIGCC) pour fonctionner, s'intègre avec l'arborescence du système plutôt que de tout installer dans son propre répertoire, peut être installé dans /usr/bin ou /usr/local/bin sans rentrer gravement en conflit avec les exécutables de base du système (gcc, as et autres - ce point-là est corrigé dans GCC4TI Git), etc.


Le principal élément restant sur la todo list de GCC4TI est justement de rendre sain le système de build, pour réduire très fortement la barrière héritée entre mainteneur et utilisateur smile
Une telle barrière mise en place par le mainteneur est efficace pour se rendre indispensable, surtout si le mainteneur prend soin de ne pas la documenter, mais nuisible.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.