Pourquoi toujours ./configure; faire; faire installer; en 3 étapes séparées?

Question

Chaque fois que vous compilez quelque chose à partir de la source, vous allez à travers la même en 3 étapes:

$ ./configure
$ make
$ make install

Je comprends, il est judicieux de diviser l'installation de processus en différentes étapes, mais je ne comprends pas, pourquoi chaque codeur sur cette planète a à écrire les trois mêmes commandes, encore et encore juste pour obtenir un seul travail. De mon point de vue il serait totalement de sens d'avoir un ./install.sh script automatiquement livré avec le code source qui contient le texte suivant:

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

pourquoi les gens faire les 3 étapes séparément?

Answer 1

Parce que chaque étape ne choses différentes

Préparer(configuration) de l'environnement pour la construction de

./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. Aussi ./configure contrôle de l'absence de bibliothèques qui doit être installé. Quelque chose de mal ici, les causes de ne pas construire votre application. C'est pourquoi les distributions ont des paquets qui sont installés dans des endroits différents, car chaque distro choses, il est préférable d'installer certains fichiers et bibliothèques, à certains répertoires. Il est dit que les ./configure, mais en fait, vous devriez le changer toujours.

Par exemple, avoir un regard sur Archlinux paquets site: http://www.archlinux.org/packages/. Ici, vous verrez que tout paquet d'utiliser un autre configurer les paramètres (à supposer qu'ils utilisent les autotools pour la construction du système).

La construction du système

make

C'est en fait make all par défaut. Et chaque marque a différentes actions à faire. Certains de la construction, de certains faire des tests après la construction, certains ne caisse de externe scm des dépôts. Habituellement, vous n'avez pas à faire toute paramater, mais encore une fois certains paquets d'exécution différents.

Installer le système

make install

Cette installation est le paquet à l'endroit spécifié à configurer. Si vous le souhaitez, vous pouvez spécifier ./configure pour pointer vers votre répertoire d'accueil. Cependant beaucoup de configurer les options sont pointant vers /usr ou /usr/local. Cela signifie que vous devez utiliser réellement sudo make install. Parce que seul root peut copier des fichiers de /usr et /usr/local.

---

Maintenant, vous voyez que chaque étape est un pré-requis pour l'étape suivante. Chaque étape est une préparation pour faire des choses de travail dans un problemless flux. Distributions utilise cette métaphore pour construire des paquets (comme le rpm, deb, etc..).

Ici, vous verrez que chaque étape est en fait un état différent de l'état. C'est pourquoi les gestionnaires de paquets ont différentes formes. Ci-dessous est un exemple d'un wrapper qui, comme vous, construire en une seule étape, l'ensemble du paquet. Mais rappelez-vous que chaque application a une autre wrapper (en fait, ces gestionnaires 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 les autotools, cela signifie que ./configure, make et make install. Mais d'un autre on peut utiliser scons, python liés à l'installation ou quelque chose de différent.

Comme vous le voyez, le fractionnement de chaque état rend les choses beaucoup plus facile pour le maintien et le déploiement, en particulier pour les mainteneurs de paquets et des distributions.

Answer 2

Tout d'abord, il convient ./configure && make && make install depuis chacun s'appuie sur le succès de l'ancienne. Partie de la raison est une évolution et une partie de la raison est pratique pour le développement de flux de travail.

À l'origine, la plupart des Makefiles ne peut contenir que des commandes pour compiler un programme et l'installation a été laissé à l'utilisateur. Une règle permet d' make install à la place de la sortie compilée dans un endroit qui pourrait être correct; il ya encore beaucoup de bonnes raisons que vous ne pourriez pas vouloir faire cela, notamment de ne pas être l'administrateur du système, souhaitez pas l'installer du tout. De plus, si je développe le logiciel, je ne veux pas l'installer. Je tiens à faire quelques changements et le test de la version assis dans mon répertoire. Cela devient encore plus saillant si je vais avoir plusieurs versions qui traînent.

./configure va et détecte ce qui est disponible dans l'environnement et/ou est souhaitée par l'utilisateur pour déterminer la façon de construire le logiciel. Ce n'est pas quelque chose qui doit changer très souvent, et peut parfois prendre un certain temps. Encore une fois, si je suis un développeur, ça ne vaut pas le temps de reconfigurer en permanence. Plus important encore, depuis make utilise les horodatages de reconstruire des modules, si je réexécuter configure il y a une possibilité que les drapeaux vont changer, et maintenant certains des composants dans mon build sera de compiler une série de drapeaux et d'autres avec un autre ensemble d'indicateurs qui pourraient conduire à des différents, incompatibles comportement. Tellement longtemps que je n'ai pas réexécuter configure,, je sais que mon environnement de compilation reste le même, même si je change mes sources. Si je réexécuter configure, je devrais make clean tout d'abord, de supprimer tout construit sources pour vous assurer que les choses sont construites de manière uniforme.

Le seul cas où les trois de commande sont exécutés dans une rangée sont lorsque les utilisateurs installent le programme ou un paquet est construit (par exemple, Debian debuild ou de RedHat rpmbuild). Et qui suppose que le paquet peut être donné une plaine configure, ce qui n'est généralement pas le cas pour l'emballage, où, au moins, --prefix=/usr est souhaitée. Et pacakgers sont comme d'avoir à traiter avec des faux-racines lors de la make install partie. Depuis, il y a beaucoup d'exceptions, rendant ./configure && make && make install la règle serait gênant pour beaucoup de gens qui le font sur une base plus fréquente!

Answer 3

configure peut échouer si elle constate que les dépendances sont manquantes.

make exécute une cible par défaut, le premier de la liste dans le fichier Makefile. Souvent, cette cible est - all, mais pas toujours. Donc, vous ne pouviez make all install si tu savais que c'était la cible.

Alors ...

#!/bin/sh

if ./configure $*; then
  if make; then
    make install
  fi
fi

ou:

./configure $* && ./make && ./make install

L' $* est inclus parce que l'on a souvent fournir des options configure.

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

Answer 4

Tout d'abord ./configurer n'en trouve pas toujours tout ce dont il a besoin, ou dans d'autres cas, il trouve tout ce qu'il exige, mais pas tout ce qu'elle pouvait utiliser. Dans ce cas, vous voulez savoir à ce sujet (et votre ./install.sh script d'échouer de toute façon!) L'exemple classique de la non-échec, avec des conséquences involontaires, de mon point de vue, est en train de compiler des applications importantes comme ffmpeg ou mplayer. Ces bibliothèques s'ils sont disponibles, mais la compilation de toute façon si ils ne sont pas, en laissant quelques options désactivées. Le problème, c'est que vous découvrez ensuite plus tard qu'il a été compilé sans le support pour un format ou un autre, donc vous obliger à revenir en arrière et refaire.

Un autre chose ./configurer ne peu interactive vous donne la possibilité de personnaliser où sur le système de l'application sera installée. Les différentes distributions/environnements ont différentes conventions, et vous ne voulez probablement pour coller à la convention sur votre système. Aussi, vous pouvez l'installer en local (uniquement pour moi-même). Traditionnellement l' ./configurer et à prendre les mesures nécessaires ne sont pas exécuter en tant que root, alors 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 que de l'effectuer ./install.sh la fonctionnalité dans la distribution de manière sensible - par exemple, la source Rpm + fichier spec + rpmbuild ou slackbuilds.

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