Les autotools ne sont clairement pas fait pour le monde Windows (hormis Cygwin), ils sont plutôt fait le monde Unix (au sens large), qui étaient la cible privilégiée des outils GNUs. Je doute qu'il y aie beaucoup d'alternative qui gère le cas des bibliothèques partagées sous HPUX, par exemple. Le fait qu'aujourd'hui on préfère en général cibler le triptyque macos/linux/windows, et cibler autre chose que des adeptes de la ligne de commande rend certainement l'outil inadapté aux objectifs de beaucoup de monde, mais absolument pas un outil dépassé. Jusqu'à preuve du contraire, la quasi-totalité des constituants de base d'un système linux (glibc, gcc, etc...) l'utilisent encore, par exemple.
Et je rejoins ce que disait le commentaire précédent, il n'y a aucune dépendance pour l'utilisateur final excepté le shell bourne (requis par POSIX) et la commande make. m4, comme perl et consort, c'est sur la machine du développeur que c'est nécessaire.
Parmi les autres approximations de l'article:
- il y a une commande fournie avec les autotools (autoreconf) qui remplace avantageusement les scripts autogen.sh fait maison
- 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
Le vrai point noir, ca reste la documentation, et le manque d'homogénéité des composants.
[^] # Re: Inconvénient des autotools
Posté par Guillaume Rousse . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 8.
Les autotools ne sont clairement pas fait pour le monde Windows (hormis Cygwin), ils sont plutôt fait le monde Unix (au sens large), qui étaient la cible privilégiée des outils GNUs. Je doute qu'il y aie beaucoup d'alternative qui gère le cas des bibliothèques partagées sous HPUX, par exemple. Le fait qu'aujourd'hui on préfère en général cibler le triptyque macos/linux/windows, et cibler autre chose que des adeptes de la ligne de commande rend certainement l'outil inadapté aux objectifs de beaucoup de monde, mais absolument pas un outil dépassé. Jusqu'à preuve du contraire, la quasi-totalité des constituants de base d'un système linux (glibc, gcc, etc...) l'utilisent encore, par exemple.
Et je rejoins ce que disait le commentaire précédent, il n'y a aucune dépendance pour l'utilisateur final excepté le shell bourne (requis par POSIX) et la commande make. m4, comme perl et consort, c'est sur la machine du développeur que c'est nécessaire.
Parmi les autres approximations de l'article:
- il y a une commande fournie avec les autotools (autoreconf) qui remplace avantageusement les scripts autogen.sh fait maison
- 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
Le vrai point noir, ca reste la documentation, et le manque d'homogénéité des composants.