Disons que vue la complexite d'autotools, je passe moins de temps a faire un support en live pour des config exotiques qu'a essayer de faire marcher ce bousin.
Pour te repondre, je te redonne un bon dicton d'informaticien: "Il ne faut pas reinventer la roue. Sauf quand le premier inventeur a invente une roue carree".
autotools, c'est clairement une roue carree. C'est un arrachage de cheveux a maintenir. Parmis les milliers de contributeurs et parmi la quarantaine de developpeurs principaux de KDE (qui ont un sacre niveau en informatique), il y a en tout et pour tout deux developpeurs qui comprennent completement le systeme des autotools utilise par KDE et qui sont capables de le maintenir. Ca ne fait pas beaucoup.
Les developpeurs de KDE ne prennent pas des decisions techniques a la legere. Si ils se debarrassent d'autotools, c'est que ce n'etait plus gerable.
Il y a des super projets pour remplacer autotools, qui ont tous la caracteristiques d'etre simple a utiliser et simple a faire evoluer. Deux qualite qui manquent terriblement a autotools. Je peux te dire que le type qui s'occupe d'autotools pour KDE (il me semble que c'est Stephan Kulow) est super motive pour utiliser autre chose, pour te donner une idee du truc.
Scons semble etre une alternative interessante. Il y en a d'autres. Pourquoi se prendre la tete avec un systeme super complexe quand des alternatives plus simples existent.
Faut pas etre trop sentimental. Autotools etait une bonne solution au moment ou il a ete cree, mais aujourd'hui, l'outil ne fait plus le poids. Avoir python ou perl installe sur sa machine n'est pas une contrainte extraordinaire alors qu'a l'epoque ou autotools a ete cree, sh etait la seule dependance acceptable.
Par exemple, je suis toujours choque que ./configure ne detecte pas les erreurs de syntaxes dans ses options:
./configure --enable-truc-muche ne te renverra aucune erreur. Sauf que en fait, il fallait taper:
./configure --enable-trucmuche
Et encore, ca c'est un probleme mineur d'utilisateur, rien a voir avec la complexite de la mise en place du truc.
[^] # Re: pourquoi virer autotools ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 3.4 officiellement sorti. Évalué à 8.
Pour te repondre, je te redonne un bon dicton d'informaticien: "Il ne faut pas reinventer la roue. Sauf quand le premier inventeur a invente une roue carree".
autotools, c'est clairement une roue carree. C'est un arrachage de cheveux a maintenir. Parmis les milliers de contributeurs et parmi la quarantaine de developpeurs principaux de KDE (qui ont un sacre niveau en informatique), il y a en tout et pour tout deux developpeurs qui comprennent completement le systeme des autotools utilise par KDE et qui sont capables de le maintenir. Ca ne fait pas beaucoup.
Les developpeurs de KDE ne prennent pas des decisions techniques a la legere. Si ils se debarrassent d'autotools, c'est que ce n'etait plus gerable.
Il y a des super projets pour remplacer autotools, qui ont tous la caracteristiques d'etre simple a utiliser et simple a faire evoluer. Deux qualite qui manquent terriblement a autotools. Je peux te dire que le type qui s'occupe d'autotools pour KDE (il me semble que c'est Stephan Kulow) est super motive pour utiliser autre chose, pour te donner une idee du truc.
Scons semble etre une alternative interessante. Il y en a d'autres. Pourquoi se prendre la tete avec un systeme super complexe quand des alternatives plus simples existent.
Faut pas etre trop sentimental. Autotools etait une bonne solution au moment ou il a ete cree, mais aujourd'hui, l'outil ne fait plus le poids. Avoir python ou perl installe sur sa machine n'est pas une contrainte extraordinaire alors qu'a l'epoque ou autotools a ete cree, sh etait la seule dependance acceptable.
Par exemple, je suis toujours choque que ./configure ne detecte pas les erreurs de syntaxes dans ses options:
./configure --enable-truc-muche ne te renverra aucune erreur. Sauf que en fait, il fallait taper:
./configure --enable-trucmuche
Et encore, ca c'est un probleme mineur d'utilisateur, rien a voir avec la complexite de la mise en place du truc.