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

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?

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.

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!

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).

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?