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

make install ubuntu (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 puede usar. En ese caso, querrá saberlo (¡y su script ./install.sh fallaría de todos modos!) Desde mi punto de vista, el ejemplo clásico de no falla con consecuencias imprevistas es compilar aplicaciones grandes como ffmpeg o mplayer. Estos usarán bibliotecas si están disponibles, pero compilarán de todos modos si no lo están, dejando algunas opciones deshabilitadas. El problema es que luego descubres que se compiló sin soporte para algún formato u otro, por lo que es necesario que regreses y lo rehagas.

Otra cosa que ./configure hace de manera 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 es probable que desee seguir 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) tiene que 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, fuentes RPM + archivo de especificaciones + rpmbuild o slackbuilds .

(Nota al pie: una vez dicho esto, acepto que ./configure; make; make install; puede volverse extremadamente tedioso.)

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 entiendo, por qué todos y cada uno de los codificadores de este planeta tienen que escribir los mismos tres comandos una y otra vez para realizar un solo trabajo. Desde mi punto de vista, sería totalmente lógico tener un script ./install.sh 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 debes cambiar. Me gusta --prefix o --with-dir=/foo . Eso significa que cada sistema tiene una configuración diferente. Además, ./configure verifica si faltan bibliotecas que deben instalarse. Cualquier error aquí provoca que no se genere su aplicación . Es por eso que las distribuciones tienen paquetes que están instalados en diferentes lugares, porque cada distribución piensa que es mejor instalar ciertas bibliotecas y archivos en ciertos directorios. Se dice que ejecuta ./configure , pero de hecho debes cambiarlo siempre.

Por ejemplo, eche un vistazo al sitio de paquetes de Arch Linux . Aquí verá que cualquier paquete utiliza un parámetro de configuración diferente (suponiendo que están utilizando 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 para hacer. Algunos construyen, otros hacen pruebas después de la construcción, otros lo hacen desde repositorios externos de SCM. Usualmente no tiene que dar 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 ./configure para que apunte a su directorio de inicio. Sin embargo, muchas opciones de configuración apuntan a /usr o /usr/local . Esto significa que debe usar sudo make install porque solo root puede copiar archivos a / usr y / usr / local.

Ahora puede 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. Los distribuidores usan 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 contenedores. A continuación se muestra un ejemplo de un contenedor que le permite construir todo el paquete en un solo paso. Pero recuerde que cada aplicación tiene un contenedor diferente (en realidad estas envolturas tienen un nombre como especificaciones, 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, eso significa ./configure , make y make install . Pero otro puede usar SCons, configuración relacionada con Python o algo diferente.

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

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 los Makefile s solo contenían los comandos para compilar un programa y la instalación se dejaba al usuario. Una regla adicional permite que make install coloque 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, 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 múltiples versiones por ahí.

./configure va y detecta qué está disponible en el entorno y / o qué desea el usuario para determinar cómo crear el software. Esto no es algo que deba cambiar muy a menudo y, a menudo, puede llevar un tiempo. Nuevamente, si soy un desarrollador, no vale la pena el tiempo para reconfigurarme constantemente. Más importante aún, dado que make usa marcas de tiempo para reconstruir módulos, si vuelvo a ejecutar configure hay una 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. Siempre que no vuelva a ejecutar la configure , sé que mi entorno de compilación sigue siendo el mismo, incluso si cambio mis fuentes. Si vuelvo a configure , primero debería make clean , para eliminar las fuentes creadas para garantizar que las cosas se construyan uniformemente.

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

configure puede fallar si descubre que faltan dependencias.

make ejecuta un objetivo predeterminado, el primero que figura en el Makefile. A menudo, este objetivo es all , pero no siempre. Entonces solo puedes make all install si sabes que ese es el objetivo.

Asi que ...

#!/bin/sh if ./configure $*; then if make; then make install fi fi

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

El $* está incluido porque a menudo hay que proporcionar opciones para configure .

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