Pourquoi toujours ./configure; faire; faire installer; en 3 étapes distinctes?

Chaque fois que vous compilez quelque chose à partir des sources, vous suivez 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 sur cette planète doit écrire les mêmes trois commandes encore et encore juste pour faire un seul travail. De mon point de vue, il serait tout à fait logique d'avoir un ./install.shscript livré automatiquement avec le code source qui contient le texte suivant:

#!/bin/sh
./configure
make
make install

pourquoi les gens feraient-ils les 3 étapes séparément?

Parce que chaque étape fait des choses différentes

Préparer (configurer) l'environnement pour la construction

./configure

Ce script a beaucoup d'options que vous devriez changer. Comme --prefixou --with-dir=/foo. Cela signifie que chaque système a une configuration différente. ./configureVérifie également les bibliothèques manquantes qui doivent être installées. Tout problème ici empêche la création de votre application . C'est pourquoi les distributions ont des packages installés à des endroits différents, car chaque distribution pense qu'il est préférable d'installer certaines bibliothèques et certains fichiers dans certains répertoires. On dit qu'il fonctionne ./configure, mais en fait, vous devriez toujours le changer.

Par exemple, jetez un œil au site des packages Arch Linux . Ici, vous verrez que tout package utilise un paramètre de configuration différent (supposons qu'ils utilisent des outils automatiques pour le système de construction).

Construire le système

make

C'est en fait make allpar défaut. Et chaque marque a des actions différentes à faire. Certains font la construction, certains font des tests après la construction, certains font l'extraction à partir de référentiels SCM externes. Habituellement, 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

Cela installe le package à l'emplacement spécifié avec configure. Si vous le souhaitez, vous pouvez spécifier ./configurede pointer vers votre répertoire de base. Cependant, de nombreuses options de configuration pointent vers /usrou /usr/local. Cela signifie que vous devez utiliser réellement sudo make installparce que seul root peut copier des fichiers vers / usr et / usr / local.

Vous voyez maintenant que chaque étape est une condition préalable à l'étape suivante. Chaque étape est une préparation pour faire fonctionner les choses dans un flux sans problème. Les distributions utilisent cette métaphore pour construire des packages (comme RPM, deb, etc.).

Ici, vous verrez que chaque étape est en fait un état différent. C'est pourquoi les gestionnaires de packages ont des wrappers différents. Vous trouverez ci-dessous un exemple de wrapper qui vous permet de créer l'ensemble du package 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, makeet make install. Mais un autre peut utiliser des SCons, une configuration liée à Python ou quelque chose de différent.

Comme vous le voyez, le fractionnement de chaque état facilite grandement la maintenance et le déploiement, en particulier pour les mainteneurs de paquets et les distributions.

Premièrement, cela devrait l'être ./configure && make && make installpuisque chacun dépend du succès du premier. Une partie de la raison est l'évolution et une partie de la raison est la commodité du flux de travail de développement.

À l'origine, la plupart des Makefiles ne contenaient que les commandes pour compiler un programme et l'installation était laissée à l'utilisateur. Une règle supplémentaire permet make installde placer la sortie compilée à un endroit qui pourrait être correct; il y a encore beaucoup de bonnes raisons pour lesquelles vous pourriez ne pas vouloir faire cela, y compris ne pas être l'administrateur système, ne pas vouloir du tout l'installer. De plus, si je développe le logiciel, je ne veux probablement pas l'installer. Je souhaite apporter des modifications et tester la version se trouvant dans mon répertoire. Cela devient encore plus évident si je vais avoir plusieurs versions qui traînent.

./configureva et détecte ce qui est disponible dans l'environnement et / ou est souhaité par l'utilisateur pour déterminer comment construire le logiciel. Ce n'est pas quelque chose qui doit changer très souvent et qui peut souvent prendre un certain temps. Encore une fois, si je suis développeur, cela ne vaut pas la peine de se reconfigurer constamment. Plus important encore, comme makeutilise des horodatages pour reconstruire les modules, si je réexécute, configureil y a une possibilité que les indicateurs changent et maintenant certains des composants de ma construction seront compilés avec un ensemble d'indicateurs et d'autres avec un ensemble différent d'indicateurs qui pourraient conduire à 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 mes sources. Si je relance configure, je devraismake clean tout d'abord, pour 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 paquet est construit (par exemple, debuild de Debian ou rpmbuild de RedHat). Et cela suppose que le colis puisse avoir un aspect uni configure, ce qui n'est généralement pas le cas pour l'emballage, où, au moins, --prefix=/usrest souhaité. Et les pacakgers sont comme avoir à faire face à de fausses racines lorsqu'ils font la make installpièce. Comme il y a beaucoup d'exceptions, faire ./configure && make && make installla règle serait gênant pour beaucoup de gens qui le font beaucoup plus fréquemment!

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 pourrait utiliser. Dans ce cas, vous voudriez en savoir plus (et votre script ./install.sh échouerait de toute façon!) 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. Ceux-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 est de vous donner la possibilité de personnaliser où sur le système l'application sera installée. Différentes distributions / environnements ont des conventions différentes, et vous voudrez probablement vous en tenir à la convention sur votre système. De plus, 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 (à moins qu'il ne soit 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, les RPM sources + le fichier de spécifications + rpmbuild ou slackbuilds .

(Note de bas de page: cela étant dit, je suis d'accord que ./configure; make; make install; peut devenir extrêmement fastidieux.)

configure peut échouer s'il constate que des dépendances sont manquantes.

makeexécute une cible par défaut, la première répertoriée dans le Makefile. Souvent, cet objectif l'est all, mais pas toujours. Donc, vous ne le pourriez que make all installsi 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 proposer des options configure.

Mais pourquoi ne pas laisser les gens le faire eux-mêmes? Est-ce vraiment une si grosse victoire?