Autoconf et Automake ont été conçus pour résoudre un problème évolutif d'Unix.
Comme Unix a évolué dans différentes directions, les développeurs qui voulaient du code portable avaient tendance à écrire du code comme ceci:
#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif
Comme Unix était divisé en différentes implémentations (BSD, SystemV, de nombreuses fourchettes de fournisseurs, et plus tard Linux et d'autres systèmes de type Unix), il est devenu important pour les développeurs qui voulaient écrire du code portable d'écrire du code qui ne dépendait pas d'une marque particulière de système d'exploitation. , mais sur les fonctionnalités exposées par le système d'exploitation. Ceci est important car une version Unix introduirait une nouvelle fonctionnalité, par exemple l'appel système "envoyer", et plus tard d'autres systèmes d'exploitation l'adopteraient. Au lieu d'avoir un spaghetti de code qui vérifiait les marques et les versions, les développeurs ont commencé à sonder les fonctionnalités, le code est donc devenu:
#if HAVE_SEND
Use Send here
#else
Use something else
#endif
La plupart des fichiers LISEZMOI pour recompiler le code source dans les années 90, les développeurs pour éditer un fichier config.h et commenter les fonctionnalités appropriées disponibles sur le système, ou expédieraient des fichiers config.h standard pour chaque configuration de système d'exploitation qui avait été testée.
Ce processus était à la fois lourd et sujet aux erreurs et c'est ainsi qu'Autoconf a vu le jour. Vous devriez penser à Autoconf comme un langage composé de commandes shell avec des macros spéciales qui ont pu remplacer le processus d'édition humaine de config.h par un outil qui a sondé le système d'exploitation pour la fonctionnalité.
Vous écrivez généralement votre code de vérification dans le fichier configure.ac, puis exécutez la commande autoconf qui compilera ce fichier dans la commande de configuration exécutable que vous avez vue utilisée.
Ainsi, lorsque vous exécutez, ./configure && make
vous testez les fonctionnalités disponibles sur votre système, puis vous construisez l'exécutable avec la configuration détectée.
Lorsque des projets open source ont commencé à utiliser des systèmes de contrôle de code source, il était logique d'archiver le fichier configure.ac, mais pas le résultat de la compilation (configure). Le autogen.sh est simplement un petit script qui appelle le compilateur autoconf avec les bons arguments de commande pour vous.
-
Automake est également né des pratiques existantes dans la communauté. Le projet GNU a normalisé un ensemble régulier de cibles pour les Makefiles:
make all
construirait le projet
make clean
supprimerait tous les fichiers compilés du projet
make install
installerait le logiciel
- des choses comme
make dist
et make distcheck
préparerait la source pour la distribution et vérifierait que le résultat était un package complet de code source
- etc...
La construction de makefiles conformes est devenue fastidieuse car il y avait beaucoup de passe-partout qui se répétaient encore et encore. Automake était donc un nouveau compilateur qui s'intégrait à autoconf et traitait les Makefile "source" (nommés Makefile.am) en Makefiles qui pouvaient ensuite être fournis à Autoconf.
La chaîne d'outils automake / autoconf utilise en fait un certain nombre d'autres outils d'assistance et ils sont augmentés par d'autres composants pour d'autres tâches spécifiques. Au fur et à mesure que la complexité de l'exécution de ces commandes dans l'ordre augmentait, le besoin d'un script prêt à exécuter est né, et c'est de là que vient autogen.sh.
Pour autant que je sache, Gnome était un projet qui a introduit l'utilisation de ce script d'aide autogen.sh