Zerosquare (./1939) :
Chapeau, t'es presque autant de mauvaise foi que Kevin quand tu t'y mets

A moitié.Je ne sais pas si ca a été réglé avec Win10.

Kevin Kofler (./1942) :
Non, parce que ça implique plein de choix de conception très discutables:

Ah !

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 ),

Sûr. Il y en a beaucoup:

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

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,

Les arguments ontologiques ne comptent pas !

utilisation du langage shell, particulièrement inefficace niveau performance (langage interprété, processus externes),

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

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

$ cmake
bash: cmake: command not found

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.

Option --with-kde4-lib= manquante ?

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 ?

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.

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

Je n'ai pas de tels souvenirs. 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.

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)

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.

Suivre un bon tutorial me semble être un bon départ : https://autotools.io/index.html