Pourquoi toujours ./configure; faire; faire installer; en 3 étapes séparées?
Chaque fois que vous compilez quelque chose à partir de la source, vous passez par les 3 mêmes étapes:
$ ./configure
$ make
$ make install
Je comprends qu'il est logique de diviser le processus d'installation en différentes étapes, mais je ne comprends pas pourquoi chaque codeur de cette planète doit écrire les trois mêmes commandes encore et encore pour effectuer un travail unique. De mon point de vue, il serait tout à fait logique d'avoir un ./install.sh script livré automatiquement avec le code source contenant le texte suivant:
#!/bin/sh
./configure
make
make install
pourquoi les gens feraient les 3 étapes séparément?
Parce que chaque étape fait des choses différentes
Préparer l'environnement de configuration pour la construction
./configure
Ce script a beaucoup d'options que vous devriez changer. Comme --prefix ou --with-dir=/foo. Cela signifie que chaque système a une configuration différente. Également ./configure vérifie les bibliothèques manquantes à installer. Tout ce qui ne va pas ici ne crée pas votre application . C'est pourquoi les distributions ont des paquets installés à différents endroits, car chaque distribution pense qu'il est préférable d'installer certaines bibliothèques et certains fichiers dans certains répertoires. On dit de courir ./configure, mais en fait, vous devriez toujours le changer.
Par exemple, regardez le site des paquets Arch Linux . Ici, vous verrez que tous les paquetages utilisent un paramètre de configuration différent (supposons qu’ils utilisent autotools pour le système de construction).
Construire le système
make
C'est en fait make all par défaut. Et chaque marque a des actions différentes à faire. Certains construisent, certains testent après la construction, d'autres empruntent des dépôts de référentiels SCM externes. Généralement, vous n'avez pas à donner de paramètres, mais encore une fois, certains packages les exécutent différemment.
Installer sur le système
make install
Ceci installe le paquet à l'endroit spécifié avec configure. Si vous le souhaitez, vous pouvez spécifier ./configure pour pointer vers votre répertoire personnel. Cependant, de nombreuses options de configuration pointent vers /usr ou /usr/local. Cela signifie que vous devez utiliser réellement Sudo make install car seule la racine peut copier des fichiers dans/usr et/usr/local.
Vous voyez maintenant que chaque étape est une condition préalable à la prochaine étape. Chaque étape est une préparation pour que les choses fonctionnent dans un flux sans problème. Distros utilise cette métaphore pour construire des packages (tels que RPM, deb, etc.).
Ici, vous verrez que chaque étape est en réalité un état différent. C'est pourquoi les gestionnaires de paquets ont des wrappers différents. Vous trouverez ci-dessous un exemple d'encapsuleur qui vous permet de construire le package complet en une seule étape. Mais rappelez-vous que chaque application a un wrapper différent (en fait, ces wrappers ont un nom comme spec, PKGBUILD, etc.):
def setup:
... #use ./configure if autotools is used
def build:
... #use make if autotools is used
def install:
... #use make all if autotools is used
Ici, on peut utiliser autotools, cela signifie que ./configure, make et make install. Mais un autre peut utiliser SCons, Python ou autre chose.
Comme vous le voyez, la division de chaque état facilite grandement la maintenance et le déploiement, en particulier pour les mainteneurs de paquets et les distributions.
Tout d'abord, il devrait être ./configure && make && make install puisque chacun dépend du succès de l’ancien. Une partie de la raison est liée à l'évolution et une partie de la raison est la commodité du flux de travail de développement.
A l'origine, la plupart des Makefiles ne contenaient que les commandes permettant de compiler un programme et l'installation était laissée à l'utilisateur. Une règle supplémentaire autorise make install pour placer la sortie compilée à un endroit qui pourrait être correct; il y a encore beaucoup de bonnes raisons pour ne pas le faire, notamment ne pas être l'administrateur système, ne pas vouloir l'installer du tout. De plus, si je développe le logiciel, je ne souhaite probablement pas l’installer. Je souhaite apporter des modifications et tester la version figurant dans mon répertoire. Cela devient encore plus frappant si je vais avoir plusieurs versions qui traînent.
./configure va et détecte ce qui est disponible dans l'environnement et/ou est désiré par l'utilisateur pour déterminer comment construire le logiciel. Ce n'est pas quelque chose qui doit changer très souvent et peut souvent prendre du temps. Encore une fois, si je suis un développeur, cela ne vaut pas la peine de reconfigurer constamment. Plus important encore, étant donné que make utilise des horodatages pour reconstruire les modules, si je réexécute configure, il est possible que les indicateurs changent et que certains composants de ma construction seront compilés avec un seul ensemble d'indicateurs. et d'autres avec un ensemble différent de drapeaux pouvant conduire à un comportement différent et incompatible. Tant que je ne relance pas configure, je sais que mon environnement de compilation reste le même, même si je change de source. Si je réexécute configure, je devrais make clean d'abord, supprimer toutes les sources construites pour s'assurer que les choses sont construites de manière uniforme.
Le seul cas où les trois commandes sont exécutées à la suite est lorsque les utilisateurs installent le programme ou qu'un package est créé (par exemple, le fichier debuild de Debian ou le fichier rpmbuild de RedHat). Et cela suppose que l’emballage puisse recevoir un configure simple, ce qui n’est généralement pas le cas pour l’emballage, où, au moins, --prefix=/usr est désiré. Et les pacakgers sont comme avoir à traiter avec de fausses racines quand on fait le make install partie. Comme il y a beaucoup d'exceptions, rendant ./configure && make && make install la règle serait peu pratique pour beaucoup de gens qui le font beaucoup plus fréquemment!
configure peut échouer s'il constate que des dépendances sont manquantes.
make exécute une cible par défaut, la première répertoriée dans le Makefile. Souvent, cette cible est all, mais pas toujours. Donc, vous ne pouviez que make all install si vous saviez que c'était la cible.
Alors ...
#!/bin/sh
if ./configure $*; then
if make; then
make install
fi
fi
ou:
./configure $* && ./make && ./make install
Le $* est inclus car il faut souvent fournir des options à configure.
Mais pourquoi ne pas laisser les gens le faire eux-mêmes? Est-ce vraiment une si grosse victoire?
Premièrement, ./configure ne trouve pas toujours tout ce dont il a besoin, ou dans d'autres cas, il trouve tout ce dont il a besoin mais pas tout ce qu'il peut utiliser. Dans ce cas, vous voudriez le savoir (et votre script ./install.sh échouerait quand même!) L'exemple classique de non échec avec des conséquences inattendues, de mon point de vue, est la compilation de grandes applications comme ffmpeg ou mplayer. Celles-ci utiliseront des bibliothèques si elles sont disponibles mais compileront quand même si elles ne le sont pas, laissant certaines options désactivées. Le problème est que vous découvrez ensuite plus tard qu'il a été compilé sans support pour un format ou un autre, vous obligeant ainsi à revenir en arrière et à le refaire.
Une autre chose que ./configure fait quelque peu de manière interactive consiste à vous donner la possibilité de personnaliser l'emplacement d'installation de l'application. Différentes distributions/environnements ont différentes conventions et vous voudrez probablement vous en tenir à la convention de votre système. En outre, vous voudrez peut-être l'installer localement (uniquement pour vous-même). Traditionnellement, les étapes ./configure et make ne sont pas exécutées en tant que root, tandis que make install (sauf s’il est installé uniquement pour vous-même) doit être exécuté en tant que root.
Des distributions spécifiques fournissent souvent des scripts qui exécutent cette fonctionnalité ./install.sh d'une manière sensible à la distribution - par exemple, RPM source + fichier de spécification + rpmbuild ou slackbuilds .
(Note de bas de page: cela étant dit, je conviens que ./configure; make; make install; peut devenir extrêmement fastidieux.)