Por qué siempre ./configure; hacer; hacer la instalación; como 3 pasos separados?

118

Cada vez que compila algo de la fuente, sigue 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 uno de los codificadores de este planeta tienen que escribir los mismos tres comandos una y otra vez solo para hacer un solo trabajo. Desde mi punto de vista, tendría mucho sentido tener un ./install.shscript entregado automáticamente con el código fuente que contiene el siguiente texto:

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

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

erikbwork
fuente
2
Si el sistema de compilación está escrito correctamente, y generalmente lo está, puede omitir el segundo paso.
reinierpost
Tu pregunta no es estúpida. Puede construir su programa en un entorno Linux y luego puede usarlo con alguna aplicación de virtualización o puede compilar directamente en un entorno Windows usando mingw.
Mihai8

Respuestas:

121

Porque cada paso hace cosas diferentes

Preparar (configurar) el entorno para la construcción

./configure

Este script tiene muchas opciones que debe cambiar. Me gusta --prefixo --with-dir=/foo. Eso significa que cada sistema tiene una configuración diferente. También ./configurecomprueba si faltan bibliotecas que deberían instalarse. Cualquier error aquí hace que no se cree la aplicación . Es por eso que las distribuciones tienen paquetes que se instalan en diferentes lugares, porque cada distribución cree que es mejor instalar ciertas bibliotecas y archivos en ciertos directorios. Se dice que corre./configure , pero de hecho debes cambiarlo siempre.

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

Construyendo el sistema

make

En realidad, esto es make allpor defecto. Y cada marca tiene diferentes acciones que realizar. Algunos construyen, otros hacen pruebas después de compilar, algunos hacen checkout desde repositorios SCM externos. Por lo general, no es necesario que proporcione ningún parámetro, pero nuevamente 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 ./configureque apunte a su directorio de inicio. Sin embargo, muchas opciones de configuración apuntan a /usro /usr/local. Eso significa que tienes que usar realmentesudo make install porque solo el root puede copiar archivos en / usr y / usr / local.


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

Aquí verá que cada paso es en realidad un estado diferente. Es por eso que los administradores de paquetes tienen diferentes envoltorios. A continuación se muestra un ejemplo de un contenedor que le permite crear todo el paquete en un solo paso. Pero recuerde que cada aplicación tiene un contenedor diferente (en realidad, estos contenedores 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í uno puede usar autotools, es decir ./configure, makey make install. Pero otro puede usar SCons, configuración relacionada con Python o algo diferente.

Como puede ver, dividir cada estado facilita mucho el mantenimiento y la implementación, especialmente para los mantenedores de paquetes y las distribuciones.

Fatih Arslan
fuente
23
Al leer esto nuevamente, aproximadamente un año después, debo agregar que todo tiene sentido, y aún podría haber una sola llamada de comando que realice los 3 pasos con su configuración predeterminada. Todos tienen una configuración predeterminada, de lo contrario, no podría simplemente llamarlos sin argumentos.
erikbwork
A veces puedo instalar sin hacer. ¿Qué significa esto? Si me salto make, ¿puedo simplemente hacer make install?
CMCDragonkai
3
installdepende de, allpor make installlo tanto , llamarámake all
excelente respuesta, sin embargo, no entiendo por qué a veces se requiere una instalación make y otras veces no (una sola marca, hacer toda la magia)
HanniBaL90
make installsimplemente instale varios recursos en una ubicación predefinida. Si solo le importa el archivo ejecutable, puede usar el archivo ejecutable del directorio de compilación y agregar el directorio de compilación a su RUTA.
jdhao
31

Primero, debería ser ./configure && make && make install ya que cada uno depende del éxito del primero. Parte del motivo es la evolución y parte es la conveniencia del flujo de trabajo de desarrollo.

Originalmente, la mayoría de los Makefilecorreos electrónicos solo contenían los comandos para compilar un programa y la instalación se dejaba al usuario. Una regla adicional permite make installcolocar la salida compilada en un lugar que podría ser correcto; todavía hay muchas buenas razones por las que es posible que no desee hacer esto, incluido no ser el administrador del sistema o no querer instalarlo en absoluto. Además, si estoy desarrollando el software, probablemente no quiera 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í.

./configureva y detecta lo que está disponible en el entorno y / o lo que el usuario desea para determinar cómo construir el software. Esto no es algo que deba cambiar con mucha frecuencia y, a menudo, puede llevar algún tiempo. Nuevamente, si soy un desarrollador, no vale la pena el tiempo para reconfigurarlo constantemente. Más importante aún, dado que makeusa marcas de tiempo para reconstruir módulos, si vuelvo a ejecutar configureexiste 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 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, deberíamake clean en primer lugar, eliminar las fuentes integradas para garantizar que las cosas se construyan de manera uniforme.

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 al paquete se le puede dar un liso configure, lo que no suele ser el caso de los empaques, donde, al menos, --prefix=/usrse desea. Y los pacakgers son como tener que lidiar con raíces falsas al hacer el make installpapel. Dado que hay muchas excepciones, hacer./configure && make && make install la regla sería inconveniente para muchas personas que lo hacen con mucha más frecuencia!

apmasell
fuente
2
Gracias por el consejo con el &&!
erikbwork
4

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, querrá saberlo (¡y su script ./install.sh fallaría de todos modos!). El ejemplo clásico de no fallar con consecuencias no deseadas, desde mi punto de vista, es compilar aplicaciones grandes 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 algunas opciones deshabilitadas. El problema es que luego descubre más tarde que se compiló sin soporte para algún formato u otro, por lo que es necesario volver atrás y rehacerlo.

Otra cosa que hace ./configure de forma algo interactiva es darle la opción de personalizar en qué parte del sistema se instalará la aplicación. Diferentes distribuciones / entornos tienen diferentes convenciones, y probablemente querrá ceñirse a la convención en su sistema. Además, es posible que desee instalarlo localmente (solo para usted). Tradicionalmente, los pasos ./configure y make no se ejecutan como root, mientras que make install (a menos que esté instalado únicamente para usted) debe ejecutarse como root.

Las distribuciones específicas a menudo proporcionan scripts que realizan esta funcionalidad ./install.sh de una manera sensible a la distribución, por ejemplo, RPM de origen + archivo de especificaciones + rpmbuild o slackbuilds .

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

Soz
fuente
Todo es comprensible, pero en mi opinión, ninguna de estas posibilidades se destruye si tiene un archivo adicional que combine los tres pasos. Por ejemplo, si desea leer algo de la salida estándar de configuración, aún puede hacer grep o poner toda la salida estándar en un archivo y leerlo después.
erikbwork
3
Es cierto, pero entonces, ¿por qué se requiere un archivo? Simplemente use un alias (aunque tendrá que pensar en un nombre mejor / más corto que 'confmakeins', ¡hoy no estoy inspirado!). alias confmakeins = '. / configure && make && sudo make install'; directorio fuente cd; confmakeins;
Soz
Suena bien. Yo nunca escribí un alias, ¡así que no pensé en eso!
erikbwork
3

configure puede fallar si encuentra que faltan dependencias.

makeejecuta un destino predeterminado, el primero que aparece en el Makefile. A menudo, este objetivo lo es all, pero no siempre. Así que solo podrías make all installsi supieras que ese era el objetivo.

Entonces ...

#!/bin/sh

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

o:

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

Se $*incluye porque a menudo hay que ofrecer opciones paraconfigure .

Pero, ¿por qué no dejar que la gente lo haga ellos mismos? ¿Es esto realmente una gran victoria?

ghoti
fuente
1
No es muy importante, pero se trata de lo que hacemos los programadores: hacer que la computadora haga las tareas repetitivas por nosotros. ¿Correcto?
erikbwork
1
Bueno ... configurees parte del kit de herramientas GNU Automake, que es una especie de complemento de Make. Make ha existido durante muchos años y hace bien su trabajo. Dicho esto, la gente ha ideado otras formas de manejar el proceso de creación. Ant y cmake tienen sus seguidores. Pero las partes del proceso de compilación (como configurar, compilar e instalar) siguen siendo comandos separados.
ghoti