Perché sempre ./configure; rendere; fare installare; come 3 passaggi separati?

Ogni volta che compili qualcosa dal sorgente, segui gli stessi 3 passaggi:

$ ./configure
$ make
$ make install

Capisco che ha senso dividere il processo di installazione in diversi passaggi, ma non capisco, perché ogni programmatore su questo pianeta deve scrivere gli stessi tre comandi ancora e ancora solo per completare un singolo lavoro. Dal mio punto di vista avrebbe assolutamente senso avere uno ./install.shscript consegnato automaticamente con il codice sorgente che contiene il seguente testo:

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

perché le persone dovrebbero eseguire i 3 passaggi separatamente?

Perché ogni passaggio fa cose diverse

Preparare (configurazione) l'ambiente per la costruzione

./configure

Questo script ha molte opzioni che dovresti modificare. Come --prefixo --with-dir=/foo. Ciò significa che ogni sistema ha una configurazione diversa. ./configureControlla anche le librerie mancanti che dovrebbero essere installate. Qualcosa di sbagliato qui fa sì che non crei la tua applicazione . Ecco perché le distribuzioni hanno pacchetti installati in luoghi diversi, perché ogni distribuzione pensa che sia meglio installare determinate librerie e file in determinate directory. Si dice che funzioni ./configure, ma in realtà dovresti cambiarlo sempre.

Ad esempio, dai un'occhiata al sito dei pacchetti di Arch Linux . Qui vedrai che ogni pacchetto utilizza un parametro di configurazione diverso (supponiamo che stia usando autotools per il sistema di compilazione).

Costruire il sistema

make

Questo è in realtà make allper impostazione predefinita. E ogni marca ha azioni diverse da fare. Alcuni compilano, altri eseguono test dopo la compilazione, altri eseguono il checkout da repository SCM esterni. Di solito non è necessario fornire alcun parametro, ma di nuovo alcuni pacchetti li eseguono in modo diverso.

Installa nel sistema

make install

Questo installa il pacchetto nella posizione specificata con configure. Se vuoi puoi specificare ./configuredi puntare alla tua directory home. Tuttavia, molte opzioni di configurazione puntano a /usro /usr/local. Ciò significa che devi usare effettivamente sudo make installperché solo root può copiare file in / usr e / usr / local.

Ora vedi che ogni passaggio è un prerequisito per il passaggio successivo. Ogni passaggio è una preparazione per far funzionare le cose in un flusso senza problemi. Le distribuzioni usano questa metafora per creare pacchetti (come RPM, deb, ecc.).

Qui vedrai che ogni passaggio è in realtà uno stato diverso. Ecco perché i gestori di pacchetti hanno wrapper diversi. Di seguito è riportato un esempio di wrapper che consente di creare l'intero pacchetto in un unico passaggio. Ma ricorda che ogni applicazione ha un wrapper diverso (in realtà questi wrapper hanno un nome come spec, PKGBUILD, ecc.):

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

Qui si possono usare autotools, che significa ./configure, makee make install. Ma un altro può usare SCons, impostazioni relative a Python o qualcosa di diverso.

Come puoi vedere, la divisione di ogni stato rende le cose molto più semplici per la manutenzione e la distribuzione, specialmente per i manutentori e le distribuzioni dei pacchetti.

In primo luogo, dovrebbe essere ./configure && make && make installpoiché ciascuno dipende dal successo del primo. Parte del motivo è l'evoluzione e parte del motivo è la comodità per il flusso di lavoro di sviluppo.

In origine, la maggior parte Makefiledei messaggi di posta elettronica conteneva solo i comandi per compilare un programma e l'installazione era lasciata all'utente. Una regola aggiuntiva consente make installdi posizionare l'output compilato in un posto che potrebbe essere corretto; ci sono ancora molte buone ragioni per cui potresti non voler farlo, incluso non essere l'amministratore di sistema, non volerlo affatto installare. Inoltre, se sto sviluppando il software, probabilmente non voglio installarlo. Voglio apportare alcune modifiche e testare la versione che si trova nella mia directory. Questo diventa ancora più importante se avrò più versioni in giro.

./configureva e rileva ciò che è disponibile nell'ambiente e / o è desiderato dall'utente per determinare come costruire il software. Questo non è qualcosa che deve cambiare molto spesso e spesso può richiedere del tempo. Anche in questo caso, se sono uno sviluppatore, non vale la pena riconfigurare costantemente. Ancora più importante, poiché makeutilizza i timestamp per ricostruire i moduli, se rieseguo configurec'è la possibilità che i flag cambino e ora alcuni dei componenti nella mia build saranno compilati con un set di flag e altri con un diverso set di flag che potrebbero portare a comportamento diverso e incompatibile. Finché non riesco a rieseguire configure, so che il mio ambiente di compilazione rimane lo stesso anche se cambio i sorgenti. Se dovessi rieseguire configure, dovreimake clean in primo luogo, rimuovere qualsiasi sorgente compilata per garantire che le cose siano costruite in modo uniforme.

L'unico caso in cui i tre comandi vengono eseguiti di seguito è quando gli utenti installano il programma o viene compilato un pacchetto (ad esempio, debuild di Debian o rpmbuild di RedHat). E ciò presuppone che al pacco possa essere data una pianura configure, cosa che di solito non è il caso del confezionamento, dove, almeno, --prefix=/usrè desiderato. E i pacakger sono come avere a che fare con radici false quando fanno la make installparte. Poiché ci sono molte eccezioni, fare ./configure && make && make installla regola sarebbe scomodo per molte persone che lo fanno su una base molto più frequente!

In primo luogo ./configure non trova sempre tutto ciò di cui ha bisogno, o in altri casi trova tutto ciò di cui ha bisogno ma non tutto ciò che potrebbe usare. In tal caso vorresti saperlo (e il tuo script ./install.sh fallirebbe comunque!) Il classico esempio di non fallimento con conseguenze indesiderate, dal mio punto di vista, è la compilazione di applicazioni di grandi dimensioni come ffmpeg o mplayer. Questi useranno le librerie se sono disponibili, ma si compileranno comunque se non lo sono, lasciando alcune opzioni disabilitate. Il problema è che poi scopri in seguito che è stato compilato senza il supporto per un formato o un altro, richiedendo quindi di tornare indietro e rifarlo.

Un'altra cosa che ./configure fa in modo piuttosto interattivo è darti la possibilità di personalizzare la posizione in cui verrà installata l'applicazione sul sistema. Distribuzioni / ambienti diversi hanno convenzioni diverse e probabilmente vorrai attenersi alla convenzione sul tuo sistema. Inoltre, potresti volerlo installare localmente (esclusivamente per te stesso). Tradizionalmente i passaggi ./configure e make non vengono eseguiti come root, mentre make install (a meno che non sia installato esclusivamente per te) deve essere eseguito come root.

Le distribuzioni specifiche spesso forniscono script che eseguono questa funzionalità ./install.sh in modo sensibile alla distribuzione, ad esempio RPM sorgente + file spec + rpmbuild o slackbuilds .

(Nota in calce: detto questo, sono d'accordo che ./configure; make; make install; può diventare estremamente noioso.)

configure potrebbe non riuscire se rileva che mancano le dipendenze.

makeesegue un target predefinito, il primo elencato nel Makefile. Spesso questo obiettivo lo è all, ma non sempre. Quindi potresti solo make all installse sapessi che quello era l'obiettivo.

Così ...

#!/bin/sh

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

o:

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

Il $*è incluso perché si ha spesso a fornire opzioni a configure.

Ma perché non lasciare che le persone lo facciano da sole? È davvero una vittoria così grande?