PpHd (./1936) :

Kevin Kofler (./1934) :
Le mode d'utilisation conseillé est de ne pas livrer juste les vraies sources, mais aussi des fichiers prégénérés. L'idée est de ne nécessiter rien de plus qu'un "simple shell",

Et c'est très bien, non ?

Non, parce que ça implique plein de choix de conception très discutables:

• compatibilité avec tous les shells Bourne-like possibles et imaginables, aussi bogués qu'ils soient (le nombre de fois que je lis "workaround for a bug in the [OS propriétaire exotique et obsolète] sh", où "[OS propriétaire exotique et obsolète]" est très variable, c'est rarement 2 fois le même, est à vomir ),
• livraison de fichiers prégénérés dans les "sources". Un fichier prégénéré n'est par définition pas une source, il n'a rien à faire dans les sources,
• utilisation du langage shell, particulièrement inefficace niveau performance (langage interprété, processus externes),

le tout seulement pour éviter à l'utilisateur d'installer un simple exécutable.

Et les fichiers prégénérés font que si on veut corriger un bogue, ou adapter le code pour trouver une bibliothèque aux exigences d'une distribution particulière, il faut patcher tous
les logiciels qui utilisent les autotools.

Soit je n'ai absolument pas compris ce que tu racontes, soit tu ne sais vraiment pas utiliser un script configure.

Ça doit être la première solution.

Par exemple, sous Fedora, pour permettre la coexistence de kdelibs3-devel et kdelibs4-devel, kdelibs 4 a été modifié pour installer les symlinks non versionnés (comme libkdecore.so) dans un répertoire dédié (/usr/lib/kde4/devel). Avec CMake, c'était un seul fichier contenu dans le paquetage de kdelibs 4 à modifier, et ça marche pour tous les logiciels qui utilisent CMake. Mais pour les projets utilisant les autotools, il a fallu bidouiller chaque projet séparément.

Un autre exemple est la (non-)gestion de /usr/lib64 dans certaines versions de libtool, avec la fâcheuse habitude de mettre /usr/lib64 dans le RPATH (ce qui empêche de remplacer les bibliothèques système par d'autres à travers ld.so.conf.d, par exemple la libGL de NVidia, ou une libfreetype compilée avec le subpixel antialiasing, donc c'est interdit dans les paquetages Fedora). Des centaines de paquetages Fedora utilisent des patches ou workarounds pour ce problème.

Les fichiers prégénérés sont d'ailleurs totalement illisibles, parce qu'ils ont choisi de contourner les erreurs dans tous les shells Bourne-like possibles et imaginables au lieu de présupposer un shell un minimum standard.

C'est tout à fait lisible. Moche à lire, mais lisible.

Tu dois trouver les entrées de l'IOCCC lisibles, aussi, alors.

Il y a régulièrement des changements incompatibles dans le langage (une raison de plus pour laquelle ils conseillent de toujours livrer les fichiers prégénérés avec les projets ).

Les fichiers autotools proprement écrit ne sont que rarement impacté. Seuls les fichiers autotools qui tapent dans les détails d'implémentation sont impactés.Et franchement, c'est plus propre qu'avant !

Il y a eu plein de changements à plein d'endroits, certains ont impacté pratiquement tous les projets.

La bidouille m4 + shell rame à fond par rapport à un exécutable natif comme CMake.

C'est vrai. Au moins, elle marche elle.

LOL, le troll! CMake marche très bien.

Autoconf s'obstine par défaut à tester plein de propriétés que de toute façon toute source moderne présuppose depuis des années (parce qu'elles font partie par exemple du standard C de 1989/1990!). Tous ces tests pour des trucs évidents comme HAVE_STDIO_H sont ensuite complètement ignorés par pratiquement toutes les sources, ce n'est que du temps perdu pour rien.

Non. Seulement si tu lui demandes de le faire.

Plein de projets ont ces tests inutiles en pratique (cf. par exemple les libti* de Romain Liévin). Probablement parce que presque personne ne comprend vraiment les autotools, tout le monde fait du copier-coller.