Pour avoir rédigé cette partie, je ne suis pas d'accord sur ce que tu qualifies d'approximations.
il y a une commande fournie avec les autotools (autoreconf) qui remplace avantageusement les scripts autogen.sh fait maison
Pouvoir regénérer correctement le système de construction avec autoreconf est malheureusement l'exception et non pas la règle. Et c'est l'empaqueteur qui te parle. Et même quand ça passe, ça ne garantit absolument pas l'absence d'effets de bords au point que certains en déconseillent l'utilisation ou bien de s'en servir comme base pour patcher directement le système de construction. http://www.redhat.com/archives/rhl-devel-list/2008-October/msg00866.html
il y a eu effectivement des incompatibilités entre versions, particulièrement la version 1.4 qui date de l'an 2000, et celles qui ont suivi, mais rien d'exceptionnel par rapport à d'autres outils
Pourquoi la majorité des distributions GNU/Linux fournissent encore autoconf 2.13 (sorti en 1999) ? Pourquoi Debian maintient 4 version d'automake, Fedora 5 ? (non, ce n'est pas par plaisir) Même si le nombre décroit petit à petit, tu as encore des paquets qui ont encore besoin de ces versions (autoreconf et autogen.sh ne peuvent pas grand chose la plupart du temps, patcher reviendrait à remettre à plat le système de construction). Ok, ça s'améliore, mais on est encore loin des autres outils en ce domaine.
Certes, c'est symptomatique d'une mauvaise utilisation d'autotools, mais un développeur qui maitrise autotools (malgré qu'il soit le plus utilisé et le plus avancé parmi ceux discutés), ça ne court pas les rues.
Le vrai point noir, ca reste la documentation, et le manque d'homogénéité des composants.
La documentation d'autotools est certes fouillie, mais relativement complète, il y a d'excellents tutoriaux (celui d'Alexandre Duret-Lutz, l'autobook, les tutoriaux d'openismus qui présente les bases et l'utilisation non-récursive). Quant au manque d'homogénéité, c'est defective by design, à moins de réécrire en grande partie autotools, ou de se restreindre à un sous-ensemble, on ne peut faire mieux.
Le vrai problème c'est qu'autotools est trop complexe pour le développeur "moyen" (ou que le développeur "moyen" soit incapable d'appréhender celui-ci par manque de temps ou par incapacité mentale), une meilleure documentation ne changera pas significativement cet état de fait (avec les ressources sus-mentionnées, on doit pouvoir arriver à un niveau de compétences plus que suffisant pour utiliser quotidiennement autotools sans être Fabrice Bellard)
[^] # Re: Inconvénient des autotools
Posté par GeneralZod . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 4.
Pour avoir rédigé cette partie, je ne suis pas d'accord sur ce que tu qualifies d'approximations.
Pouvoir regénérer correctement le système de construction avec autoreconf est malheureusement l'exception et non pas la règle. Et c'est l'empaqueteur qui te parle. Et même quand ça passe, ça ne garantit absolument pas l'absence d'effets de bords au point que certains en déconseillent l'utilisation ou bien de s'en servir comme base pour patcher directement le système de construction.
http://www.redhat.com/archives/rhl-devel-list/2008-October/msg00866.html
Pourquoi la majorité des distributions GNU/Linux fournissent encore autoconf 2.13 (sorti en 1999) ? Pourquoi Debian maintient 4 version d'automake, Fedora 5 ? (non, ce n'est pas par plaisir) Même si le nombre décroit petit à petit, tu as encore des paquets qui ont encore besoin de ces versions (autoreconf et autogen.sh ne peuvent pas grand chose la plupart du temps, patcher reviendrait à remettre à plat le système de construction). Ok, ça s'améliore, mais on est encore loin des autres outils en ce domaine.
Certes, c'est symptomatique d'une mauvaise utilisation d'autotools, mais un développeur qui maitrise autotools (malgré qu'il soit le plus utilisé et le plus avancé parmi ceux discutés), ça ne court pas les rues.
La documentation d'autotools est certes fouillie, mais relativement complète, il y a d'excellents tutoriaux (celui d'Alexandre Duret-Lutz, l'autobook, les tutoriaux d'openismus qui présente les bases et l'utilisation non-récursive). Quant au manque d'homogénéité, c'est defective by design, à moins de réécrire en grande partie autotools, ou de se restreindre à un sous-ensemble, on ne peut faire mieux.
Le vrai problème c'est qu'autotools est trop complexe pour le développeur "moyen" (ou que le développeur "moyen" soit incapable d'appréhender celui-ci par manque de temps ou par incapacité mentale), une meilleure documentation ne changera pas significativement cet état de fait (avec les ressources sus-mentionnées, on doit pouvoir arriver à un niveau de compétences plus que suffisant pour utiliser quotidiennement autotools sans être Fabrice Bellard)