Automake et Autoconf sont-ils le moyen standard de compiler du code?

Je compile parfois des applications à partir de la source et j'utilise:

./configure
make
sudo make install

Mais récemment, je suis tombé sur ./autogen.shqui génère la configuration et crée des scripts pour moi et les exécute.

Quelles autres méthodes pour rationaliser la compilation C / C ++ / C # (mono) existent? Make semble un peu vieux. Existe-t-il de nouveaux outils? Compte tenu du choix, lequel dois-je utiliser?

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 && makevous 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 distet make distcheckpré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

Il y a deux "grands joueurs" dans ce domaine; Cmake et GNU Autotools.

• GNU Autotools est la façon GNU de faire les choses, et est assez concentré sur * nix. C'est une sorte de système de méta-construction, fournissant un ensemble d'outils qui génèrent une configuration spécifique et créent des fichiers pour ce que vous essayez de faire. Cela vous aide à apporter plus de modifications à votre code sans avoir à manipuler directement votre système de génération, et il aide les autres à créer votre code d'une manière que vous n'aviez pas conçue - sous * nix.

• Cmake est le moyen multiplateforme de faire les choses. L'équipe Cmake construit des logiciels de nombreuses façons différentes, avec GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU / Linux, peu importe. Si vous êtes préoccupé par la portabilité de votre base de code, c'est la voie à suivre.

Comme cela a été mentionné, certaines personnes semblent aimer Scons. Si vous êtes familier avec Python, cela pourrait fournir plus de cohérence dans votre environnement de travail.

Ruby a également une sorte de système de méta-construction appelé Rake, qui est assez cool en soi, et est très pratique pour ceux qui connaissent déjà Ruby.

Scons est un remplaçant possible, mais je n'ai aucune expérience personnelle. Il est également implémenté en Python, ce qui pourrait poser problème, selon l'environnement de génération.

Si vous utilisez C # / Mono, vous pouvez utiliser msbuild (les fichiers .sln / .csproj utilisés par MonoDevelop et Visual Studio) pour gérer l'ensemble de votre processus de génération.

Vous pouvez alors soit construire à partir de MonoDevelop, soit exécuter la xbuildcommande dans votre terminal préféré (fonctionne mieux en Mono> = 2.6). Ceci est extrêmement facile et ne nécessite pratiquement aucun travail de votre part, car MonoDevelop gérera les fichiers msbuild pour vous, et vous n'aurez pas besoin de les modifier, sauf si vous souhaitez modifier les choses au-delà de ce que l'interface utilisateur de MonoDevelop peut faire pour vous.

Je ne sais pas comment les gens qui dépendent de msbuild gèrent les installations pour leurs projets, mais vous pouvez toujours demander cela. ;-)

Pour C #, vous pouvez utiliser xbuild (et msbuild sur Windows), qui construira le projet à partir de vos fichiers de projet.