Ah, enfin un débat technique avec PpHd, ça me manquait! Ça change du nucléaire et des voitures. Le seul truc bizarre, c'est que c'est moi qui défends la solution qui nécessite un logiciel à installer centralement (CMake) et PpHd qui défend celle qui se contente de ce qui est déjà installé sur le système (les scripts prégénérés des autotools).

PpHd (./1944) :
Sûr. Il y en a beaucoup:

$ grep -i work configure|grep -i around| wc -l
7

Il y a aussi des commentaires formulés différemment, par exemple:
# WARNING: Do not start the trap code with a newline, due to a FreeBSD 4.0 bug.

C'est sûr que python est tellement plus rapide !

CMake est en C++, pas en Python.

$ cmake
bash: cmake: command not found

sma()
                Done

Option --with-kde4-lib= manquante ?

Déjà, comme il n'y a pas de macro standard pour trouver les kdelibs avec les autotools (normal, les autotools sont dépréciés dans KDE depuis des années, il faut utiliser CMake), les projets ont tous leurs propres bidouilles, et la plupart ne prend aucune option. Et ensuite, passer une telle option à chaque configure nécessiterait quand-même de modifier tous les specfiles; avec CMake, c'est un seul (le paquetage qui contient FindKDE4Internal.cmake, installé dans le système).

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.

autoreconf -i pour mettre à jour la version de libtool ?

Certains paquetages utilisent effectivement ça (c'est la solution la plus propre), mais ça a d'autres inconvénients (par exemple, le risque de se taper une incompatibilité entre versions), et donc certains packagers préfèrent utiliser des workarounds beaucoup plus sales dans leurs paquetages. Et puis, à quoi bon livrer les fichiers prégénérés si on doit de toute façon les regénérer?

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

C'est ce que j'ai l'impression de lire en lisant les Makefile généré par cmake pour trouver où est l'erreur qui m'emêche de compiler.

Le bordel infâme que génère automake n'est pas mieux.

De toute façon, c'est le développeur qui maitrise sa migration de version. Il peut migrer quand il veut, cela n'a pas d'impact sur l'utilisateur.

Sauf s'il doit regénérer les fichiers, soit pour corriger un bogue des générateurs (ou des fichiers copiés tels quels) (comme le cas de libtool ci-dessus), soit parce qu'il veut exercer son droit de modification sur le logiciel libre.

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

Sauf lorsqu'il récupère un mauvais compilateur,
Sauf lorsqu'il récupère une mauvaise librarie, ..
(ok, ca n'arrive pas souvent, mais lorsque ca arrive, c'est la merde)

Tu peux redéfinir pratiquement tous les chemins détectés par Find*.cmake si ceux qu'il te trouve ne te conviennent pas.