Gli autotools possono creare makefile multipiattaforma

StackOverflow https://stackoverflow.com/questions/324134

Domanda

Ho un progetto di plug-in che sto sviluppando da alcuni anni in cui il plug-in funziona con numerose combinazioni di [versione dell'applicazione primaria, versione della libreria di terze parti, 32 bit contro 64 bit]. Esiste un modo (pulito) per usare gli autotools per creare un singolo makefile che costruisce tutte le versioni del plugin.

Per quanto ne so, sfogliando la documentazione degli autotools, l'approssimazione più vicina a ciò che mi piacerebbe è avere N copie indipendenti del progetto, ognuna con il proprio makefile. Questo sembra un po 'non ottimale per i test e lo sviluppo poiché (a) avrei bisogno di propagare continuamente le modifiche al codice in tutte le diverse copie e (b) c'è un sacco di spazio sprecato nel duplicare il progetto così tante volte. C'è un modo migliore?

MODIFICA:

Ho implementato la mia soluzione per un po 'in cui ho un makefile di fantasia e alcuni script perl per dare la caccia a varie versioni di librerie di terze parti, ecc. Come tale, sono aperto ad altre soluzioni non autotools. Per altri strumenti di compilazione, vorrei che fossero molto facili da installare per gli utenti finali. Gli strumenti devono anche essere abbastanza intelligenti da dare la caccia a varie librerie e intestazioni di terze parti senza enormi problemi. Sono principalmente alla ricerca di una soluzione Linux, ma una che funzioni anche per Windows e / o Mac sarebbe un vantaggio.

È stato utile?

Soluzione

Per quanto ne so, non puoi farlo. Tuttavia, sei bloccato con gli autotools? Né CMake né SCons un'opzione?

Altri suggerimenti

Se la tua domanda è:

  

Posso usare gli autotools su alcune macchine A per creare un singolo makefile universale che funzionerà su tutte le altre macchine?

quindi la risposta è " No " ;. Gli autotools non fanno nemmeno finta di provare a farlo. Sono progettati per contenere codice portatile che determinerà come creare un makefile funzionante sul computer di destinazione.

Se la tua domanda è:

  

Posso usare gli autotools per configurare il software che deve essere eseguito su macchine diverse, con diverse versioni del software primario con cui il mio plugin funziona, oltre a varie librerie di terze parti, per non parlare dei problemi a 32 bit contro 64 bit?

allora la risposta è " Sì " ;. Gli autotools sono progettati per essere in grado di farlo. Inoltre, lavorano su Unix, Linux, MacOS X, BSD.

Ho un programma, SQLCMD (che precede il programma Microsoft con lo stesso nome di un decennio e più), che funziona con i database IBM Informix. Rileva la versione del software client (chiamato IBM Informix ESQL / C, parte di IBM Informix ClientSDK o CSDK) installata e se è a 32 o 64 bit. Rileva inoltre quale versione del software è installata e adatta la sua funzionalità a ciò che è disponibile nel prodotto di supporto. Supporta versioni che sono state rilasciate per un periodo di circa 17 anni. È autoconfigurato: ho dovuto scrivere alcune macro autoconf per la funzionalità Informix e per un paio di altri aggeggi (tempistica ad alta risoluzione, presenza di / dev / stdin ecc.). Ma è fattibile.

D'altra parte, non provo a rilasciare un singolo makefile adatto a tutte le macchine e gli ambienti dei clienti; ci sono troppe possibilità perché ciò sia sensato. Ma gli autotools si occupano dei dettagli per me (e i miei utenti). Tutto quello che fanno è: 

./configure

È più semplice che capire come modificare il makefile. (Oh, per i primi 10 anni, il programma è stato configurato a mano. È stato difficile da fare per le persone, anche se avevo impostazioni predefinite abbastanza buone. Ecco perché sono passato all'auto-configurazione: rende molto più facile per persone da installare.)

L'onorevole Fooz ha commentato:

  

Voglio qualcosa nel mezzo. Nel mio caso, i clienti useranno più versioni e testimoni della stessa applicazione di base sulla stessa macchina. Non sono preoccupato per la compilazione incrociata come la creazione di file binari di Windows su Linux.

Hai bisogno di una build separata del tuo plug-in per le versioni a 32 e 64 bit? (Suppongo di sì, ma potresti sorprendermi.) Quindi devi fornire un meccanismo che l'utente possa dire 

./configure --use-tppkg=/opt/tp/pkg32-1.0.3

(dove tppkg è un codice per il tuo pacchetto di terze parti e la posizione è specificabile dall'utente.) Tuttavia, tieni presente l'usabilità: minore è il numero di opzioni che l'utente ha da fornire, il migliore; in questo caso, non scrivere nel codice cose che dovrebbero essere facoltative, come i percorsi di installazione. Cerca in tutte le posizioni predefinite - va bene. E per impostazione predefinita la cattiveria delle cose che trovi. Forse se trovi entrambe le versioni a 32 e 64 bit, dovresti costruirle entrambe, ma ciò richiederebbe un'attenta costruzione. Puoi sempre echeggiare " Verifica del pacchetto TP ... " e indica cosa hai trovato e dove l'hai trovato. Quindi il programma di installazione può modificare le opzioni. Assicurati di documentare in ' ./configure --help ' quali sono le opzioni; questa è la pratica standard degli autotools.

Non fare nulla di interattivo; lo script di configurazione dovrebbe essere eseguito, riportando ciò che fa. Lo script Perl Configure (nota la lettera maiuscola - è un sistema di configurazione automatica completamente separato) è uno dei pochi sistemi di configurazione interattivamente intensi rimasti (e questo è probabilmente principalmente a causa della sua eredità; se ricominciare da capo , molto probabilmente non sarebbe interattivo). Tale sistema

L'abbiamo provato e non funziona! Quindi ora utilizziamo SCons .

Alcuni articoli su questo argomento: 1 e 2

Modifica Qualche piccolo esempio del perché amo SCons: 

env.ParseConfig('pkg-config --cflags --libs glib-2.0')

Con questa riga di codice aggiungi GLib all'ambiente di compilazione ( env ). E non dimenticare la Guida dell'utente che è semplicemente fantastico per imparare SCons (davvero non devi conoscere Python!). Per l'utente finale puoi provare SCons con PyInstaller o qualcosa del genere.

E rispetto a make , usi Python, quindi un linguaggio di programmazione completo! Con questo in mente puoi fare tutto (più o meno).

Hai mai pensato di usare un singolo progetto con più directory di compilazione? se il tuo progetto automake è implementato in modo corretto (cioè NON come gcc)

è possibile: 

mkdir build1 build2 build3
cd build1
../configure $(YOUR_OPTIONS)
cd build2
../configure $(YOUR_OPTIONS2)
[...]

sei in grado di passare parametri di configurazione diversi come include directory e compilatori (cross compiler cioè).

puoi anche eseguirlo in una singola chiamata eseguendo 

make -C build1 -C build2 -C build3
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top