Por qué siempre./ configure; make; make install; como 3 pasos separados?

Question

Por qué siempre./ configure; make; make install; como 3 pasos separados?

Cada vez que compilas algo desde el código fuente, pasas por los mismos 3 pasos:

$ ./configure
$ make
$ make install

Entiendo, que tiene sentido dividir el proceso de instalación en diferentes pasos, pero no lo entiendo, por qué todos y cada codificador en este planeta tiene que escribir los mismos tres comandos una y otra vez solo para conseguir un solo trabajo hecho. Desde mi punto de vista, tendría totalmente sentido tener un script ./install.sh entregado automáticamente con el código fuente que contiene lo siguiente texto:

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

¿Por qué la gente haría los 3 pasos por separado?

99

makefile unix configure make-install

Author: Cœur, 2012-06-09

Source

4 answers

Primero, debe ser ./configure && make && make install ya que cada uno depende del éxito del primero. Parte de la razón es la evolución y parte de la razón es la conveniencia para el flujo de trabajo de desarrollo.

Originalmente, la mayoría de Makefile s solo contendrían los comandos para compilar un programa y la instalación se dejaba al usuario. Una regla adicional permite a make install colocar la salida compilada en un lugar que podría ser correcto; todavía hay muchas buenas razones por las que puede no querer hacer esto, incluyendo no ser el administrador del sistema, no quiere instalarlo en absoluto. Además, si estoy desarrollando el software, probablemente no quiero instalarlo. Quiero hacer algunos cambios y probar la versión que se encuentra en mi directorio. Esto se vuelve aún más destacado si voy a tener varias versiones por ahí.

./configure va y detecta lo que está disponible en el entorno y / o es deseado por el usuario para determinar cómo construir el software. Esto no es algo que necesita cambiar muy a menudo y a menudo puede tomar algún tiempo. Una vez más, si soy un desarrollador, no vale la pena el tiempo para reconfigurar constantemente. Más importante aún, dado que make usa marcas de tiempo para reconstruir módulos, si vuelvo a ejecutar configure existe la posibilidad de que los indicadores cambien y ahora algunos de los componentes de mi compilación se compilarán con un conjunto de indicadores y otros con un conjunto diferente de indicadores que podrían conducir a un comportamiento diferente e incompatible. Mientras no vuelva a ejecutar configure, sé que mi entorno de compilación sigue siendo el mismo incluso si cambio mis fuentes. Si vuelvo a ejecutar configure, primero debo make clean eliminar cualquier fuente construida para asegurar que las cosas se construyen uniformemente.

El único caso en el que los tres comandos se ejecutan en una fila es cuando los usuarios instalan el programa o se construye un paquete (por ejemplo, debuild de Debian o rpmbuild de RedHat). Y eso supone que el paquete se puede dar un simple configure, que no suele ser el caso para el embalaje, donde, al menos, --prefix=/usr se desea. Y pacakgers son como tener que lidiar con fake-roots al hacer la parte make install. Dado que hay muchas excepciones, hacer ./configure && make && make install la regla sería inconveniente para muchas personas que lo hacen de manera mucho más frecuente.

27

Author: apmasell,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-06-09 13:47:09

configure puede fallar si encuentra que faltan dependencias.

make ejecuta un destino predeterminado, el primero listado en el Makefile. A menudo este objetivo es all, pero no siempre. Así que solo podrías make all install si supieras que ese era el objetivo.

So ...

#!/bin/sh

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

O:

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

El $* se incluye porque uno a menudo tiene que proporcionar opciones a configure.

Pero ¿por qué no dejar que la gente lo haga por sí misma? ¿Es realmente una gran victoria?

3

Author: ghoti,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-06-09 13:37:58

En primer lugar ./ configure no siempre encuentra todo lo que necesita, o en otros casos encuentra todo lo que necesita pero no todo lo que podría usar. En ese caso usted querría saber sobre él(y su. /install.sh ¡el guión fallaría de todos modos!) El ejemplo clásico de no fallo con consecuencias no deseadas, desde mi punto de vista, es compilar grandes aplicaciones como ffmpeg o mplayer. Estos usarán bibliotecas si están disponibles, pero se compilarán de todos modos si no lo están, dejando algunos opciones desactivadas. El problema es que luego descubre más tarde que se compiló sin soporte para algún formato u otro, por lo que requiere que regrese y lo vuelva a hacer.

Otra cosa ./ configure de alguna manera interactiva le está dando la opción de personalizar en qué parte del sistema se instalará la aplicación. Diferentes distribuciones / entornos tienen diferentes convenciones, y es probable que desee atenerse a la convención en su sistema. Además, es posible que desee instalar a nivel local (solo para ti). Tradicionalmente el ./ configure y make los pasos no se ejecutan como root, mientras que make install (a menos que se instale únicamente para usted) tiene que ejecutarse como root.

Distribuciones específicas a menudo proporcionan scripts que realizan esto ./install.sh funcionalidad de una manera sensible a la distribución, por ejemplo, RPMs de origen + spec file + rpmbuildo slackbuilds.

(Nota al pie: dicho esto, estoy de acuerdo ./configure; make; make install; puede ser extremadamente tedioso.)

3

Author: Soz,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-06-09 13:44:05

score 108 · Accepted Answer

Porque cada paso hace cosas diferentes

Preparar (configurar) el entorno para la construcción

./configure

Este script tiene muchas opciones que debe cambiar. Como --prefix o --with-dir=/foo. Eso significa que cada sistema tiene una configuración diferente. También ./configure comprueba si faltan bibliotecas que deban instalarse. Cualquier error aquí hace que no se compile su aplicación. Es por eso que las distribuciones tienen paquetes que se instalan en diferentes lugares, porque cada distro piensa que es es mejor instalar ciertas bibliotecas y archivos en ciertos directorios. Se dice que se ejecuta ./configure, pero de hecho se debe cambiar siempre.

Por ejemplo, eche un vistazo a el sitio de paquetes de Arch Linux. Aquí verá que cualquier paquete usa un parámetro configure diferente (suponga que está usando autotools para el sistema de compilación).

Construyendo el sistema

make

Esto es en realidad make all por defecto. Y cada marca tiene diferentes acciones que hacer. Algunos hacen la construcción, algunos hacen pruebas después de la construcción, otros hacen checkout desde repositorios SCM externos. Por lo general no tiene que dar ningún parámetro, pero de nuevo algunos paquetes los ejecutan de manera diferente.

Instalar en el sistema

make install

Esto instala el paquete en el lugar especificado con configure. Si lo desea, puede especificar ./configure para que apunte a su directorio personal. Sin embargo, muchas opciones de configuración apuntan a /usr o /usr/local. Eso significa que entonces tienes que usar realmente sudo make install porque solo root puede copiar archivos a / usr y/usr / local.

Ahora verá que cada paso es un requisito previo para el siguiente paso. Cada paso es una preparación para hacer que las cosas funcionen en un flujo sin problemas. Las distribuciones usan esta metáfora para construir paquetes (como RPM, deb, etc.).).

Aquí verás que cada paso es en realidad un estado diferente. Es por eso que los gestores de paquetes tienen diferentes envoltorios. A continuación se muestra un ejemplo de una envoltura que le permite compilar todo el paquete en un solo paso. Pero recuerda que cada la aplicación tiene una envoltura diferente(en realidad estas envolturas tienen un nombre como 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

Aquí se puede usar autotools, eso significa ./configure, make y make install. Pero otro puede usar SCons, configuración relacionada con Python o algo diferente.

Como puede ver, dividir cada estado hace las cosas mucho más fáciles para el mantenimiento y la implementación, especialmente para los mantenedores de paquetes y distribuciones.