Confuso su configure script e Makefile.in

Question

Attualmente sto imparando come utilizzare la toolchain /automake. Mi sembra di avere una comprensione generale del flusso di lavoro qui - in pratica hai uno script configure.ac che genera un file eseguibile configure. Lo script configure generato viene quindi eseguito dall'utente finale per generare Makefile s, in modo che il programma possa essere creato/installato.

Così l'installazione per un tipico utente finale è fondamentalmente:

./configure 
make 
make install 
make clean 

Okay, ora qui è dove sono confuso:

Come sviluppatore, ho notato che l'auto-generato configurare lo script a volte non funzionerà, e sarà errore con:

config.status: error: cannot find input file: `somedir/Makefile.in' 

Questo mi confonde, perché ho pensato che lo script di configurazione dovrebbe generare il Makefile.in. Quindi, cercando su Google alcune risposte, ho scoperto che questo può essere risolto con uno script autogen.sh, che sostanzialmente "ripristina" lo stato dell'ambiente autoconf. Un tipico autogen.sh sceneggiatura sarebbe qualcosa di simile:

aclocal \ 
&& automake --add-missing \ 
&& autoconf 

bene Va bene. Ma come utente finale che ha scaricato innumerevoli tarball per tutta la mia vita, io ho mai dovevo usare uno script autogen.sh. Tutto quello che ho fatto è stato decomprimere il tarball e fare il solito configure/make/make install/make clean routine.

Ma, come uno sviluppatore che ora è utilizzandoautoconf, sembra che configure in realtà non gestita a meno che non si esegue autogen.sh prima. Quindi trovo questo molto confuso, perché pensavo che l'utente finale non avrebbe dovuto eseguire autogen.sh.

Quindi, perché prima devo eseguire autogen.sh - in modo che lo script di configurazione trovi Makefile.in? Perché lo script configure non lo genera semplicemente?

Answer 1

Per comprendere veramente le utilità degli autotools bisogna ricordare da dove provengono: provengono da un mondo open source in cui vi sono (a) sviluppatori che lavorano da un repository di codice sorgente (CVS, Git, ecc.) e creando un file tar o un codice sorgente contenente simili e mettendo il file tar su un sito di download e (b) gli utenti finali che stanno ricevendo il file tar del codice sorgente, compilando il codice sorgente sul proprio sistema e utilizzando il binario risultante . Ovviamente anche i membri del gruppo (a) compilano il codice e utilizzano il binario risultante, ma i membri del gruppo (b) non hanno o hanno bisogno, spesso, di tutti gli strumenti per lo sviluppo necessari alla gente del gruppo (a).

Quindi l'uso degli strumenti è orientato verso questa scissione, in cui le persone in gruppo (b) non hanno accesso ai autoconf, automake, ecc

Quando si utilizza autoconf, la gente in genere di spunta nella configure.ac file (input per autoconf) nel controllo del codice sorgente, ma non controllare l'output di autoconf, lo script configure (alcuni progetti controllano lo script configure ovviamente: dipende da te).

Quando si utilizza automake, le persone di solito controllano il file Makefile.am (input per automake) ma non controllano l'output di automake: Makefile.in.

Lo script configure fondamentalmente esamina il sistema per vari elementi opzionali che il pacchetto può o non può avere bisogno, dove possono essere trovati, ecc. Una volta trovata questa informazione, può usarla per convertire vari file XXX.in (tipicamente , ma non solo, Makefile.in) nei file XXX (ad esempio, Makefile).

Così i passaggi in genere vanno in questo modo: scrivere configure.ac e Makefile.am e il check-in per generare il progetto dal checkout controllo del codice sorgente, autoconf correre per generare configure da configure.ac.. Eseguire automake per generare Makefile.in da Makefile.am. Esegui configure per generare Makefile da Makefile.in. Esegui make per creare il prodotto.

Quando si desidera rilasciare il codice sorgente (se si sta sviluppando un prodotto open source che rende rilasci il codice sorgente) si esegue autoconf e automake, poi impacchettare il codice sorgente con i file configure e Makefile.in, in modo che la gente costruire la tua versione del codice sorgente ha solo bisogno di make e di un compilatore e non ha bisogno di alcun autotools.

Poiché l'ordine di esecuzione di autoconf e automake (e libtool se lo si utilizza) può essere complicato ci sono script come autogen.sh e autoreconf, ecc. Che vengono controllati nel controllo sorgente per essere utilizzati dagli sviluppatori che costruiscono dal controllo sorgente , ma questi non sono necessari/utilizzati dalla gente che costruisce dal codice sorgente del file tar ecc.

Autoconf e automake vengono spesso utilizzati insieme ma è possibile utilizzare autoconf senza automake, se si desidera scrivere il proprio Makefile.in.