Quali sono le differenze tra Autotools, Cmake e Scons?

Quali sono le differenze tra Autotools, Cmake e Scons?

In verità, l'unica vera "grazia salvifica" di Autotools è che è ciò che tutti i progetti GNU utilizzano ampiamente.

Problemi con gli autotools:

• Veramente sintassi macro ARCANE m4 combinata con script shell dettagliati e contorti per test di "compatibilità", ecc.
• Se non si sta prestando attenzione, si sarà rovinare la capacità di cross-compilazione (dovrebbe chiaramente notare che Nokia si avvicinò con Scratchbox / Scratchbox2 al side-step altamente rotto Autotools configurazioni di build per Maemo / Meego.) Se, per qualsiasi motivo, hai percorsi fissi e statici nei tuoi test, interromperai il supporto della compilazione incrociata perché non rispetterà le tue specifiche sysroot e tirerà fuori le cose dal tuo sistema host. Se si interrompe il supporto per la compilazione incrociata, il codice diventa inutilizzabile per cose come OpenEmbedded e lo rende "divertente" per le distribuzioni che cercano di creare le loro versioni su un compilatore incrociato anziché sulla destinazione.
• Effettua un'enorme quantità di test per problemi con compilatori antichi e rotti che NOBODY attualmente utilizza praticamente con qualsiasi cosa di produzione al giorno d'oggi. A meno che tu non stia costruendo qualcosa come glibc, libstdc ++ o GCC su una versione veramente antica di Solaris, AIX o simili, i test sono una perdita di tempo e sono fonte di molte, molte potenziali rotture di cose come menzionate sopra.
• È quasi un'esperienza dolorosa ottenere una configurazione di Autotools per creare codice utilizzabile per un sistema Windows. (Mentre uso poco per Windows, è una preoccupazione seria se stai sviluppando presumibilmente codice multipiattaforma.)
• Quando si romperà, trascorrerai ORE a inseguire la tua coda cercando di risolvere le cose che chiunque ha scritto gli script ha sbagliato a sistemare la tua build (In realtà, questo è quello che sto cercando di fare (o, piuttosto, strappare completamente gli Autotools - Dubito che ci sia abbastanza tempo nel resto di questo mese per risolvere il pasticcio ...) per lavorare proprio ora mentre sto scrivendo questo. Apache Thrift ha uno di quei sistemi di build BROKEN che non attraverseranno -compilare.)
• Gli utenti "normali" in realtà NON faranno semplicemente "./configure; make" - per molte cose, tireranno fuori un pacchetto fornito da qualcuno, come un PPA, o il loro fornitore di distribuzione. Gli utenti "normali" non sono sviluppatori e in molti casi non stanno afferrando tarball. Questo è snobismo da parte di tutti per presumere che sarà il caso lì. Gli utenti tipici di tarball sono gli sviluppatori che fanno le cose, quindi se ne trovano vengono sbattuti.

Funziona ... il più delle volte ... è tutto ciò che puoi dire su Autotools. È un sistema che risolve diversi problemi che riguardano veramente solo il progetto GNU ... per il loro codice base, toolchain di base. (Modifica (24/05/2014): Va notato che questo tipo di preoccupazione è una cosa potenzialmente MALE di cui preoccuparsi: Heartbleed deriva in parte da questo pensiero e con sistemi corretti e moderni, davveronon ha affari a che fare con gran parte di ciò per cui Autotools corregge. GNU probabilmente ha bisogno di fare una rimozione cruft del codebase, alla luce di quello che è successo con Heartbleed) Puoi usarlo per fare il tuo progetto e potrebbe funzionare bene per un progetto piccolo che non ti aspetti di lavorare ovunque tranne Linux o dove la toolchain GNU funziona chiaramente correttamente. L'affermazione che essa "si integra bene con Linux" è piuttosto la dichiarazione coraggiosa e molto corretta . Si integra abbastanza bene con la suite di strumenti GNU e risolve i problemi che l'IT ha con i suoi obiettivi.

Questo non vuol dire che non ci sono problemi con le altre opzioni discusse nel thread qui.

SCons è più di un sostituto di Make / GMake / etc. e sembra piuttosto carino, tutto sommato Comunque ...

• È ancora più uno strumento POSIX. Probabilmente potresti ottenere più facilmente MinGW per costruire roba di Windows con questo che con Autotools, ma è ancora molto più orientato a fare cose POSIX e dovresti installare Python e SCons per usarlo.
• Ha problemi a eseguire la compilazione incrociata a meno che tu non stia usando qualcosa come Scratchbox2.
• Certamente più lento e meno stabile di CMake dal loro stesso confronto. Vengono fuori con poco rispetto (il lato POSIX ha bisogno di make / gmake per costruire ...) negativi per CMake rispetto a SCons. (A parte questo, se hai bisogno di Tanta estensibilità rispetto ad altre soluzioni, dovresti chiederti se il tuo progetto è troppo complicato ...)

Gli esempi forniti per CMake in questo thread sono un po 'falsi.

Però...

• Dovrai imparare una nuova lingua.
• Ci sono cose controintuitive se sei abituato a fare, SCon o Auto-Foto.
• Dovrai installare CMake sul sistema che stai costruendo.
• Avrai bisogno di un compilatore C ++ solido se non hai binari predefiniti per questo.

In verità, i tuoi obiettivi dovrebbero dettare ciò che scegli qui.

• Devi gestire MOLTE toolchain rotte per produrre un binario funzionante valido? In caso affermativo, potresti prendere in considerazione gli Autotools, tenendo conto degli svantaggi che ho menzionato sopra. CMake può farcela molto, ma si preoccupa meno di Autotools. Le SCons possono essere estese per preoccuparsene, ma non è una risposta pronta all'uso lì.
• Hai bisogno di preoccuparti degli obiettivi di Windows? In tal caso, gli Autotools dovrebbero essere letteralmente fuori gioco. In tal caso, SCons potrebbe / potrebbe non essere una buona scelta. In tal caso, CMake è una scelta solida.
• Hai bisogno di preoccuparti della compilazione incrociata (app / librerie universali, cose come Google Protobufs, Apache Thrift, ecc. DOVREBBE preoccuparti di questo ...)? In tal caso, Autotools potrebbelavora per te finché non devi preoccuparti di Windows, ma passerai molto tempo a mantenere il tuo sistema di configurazione man mano che le cose cambiano su di te. SCons è quasi un no-go al momento, a meno che tu non stia usando Scratchbox2- in realtà non ha un controllo sulla compilazione incrociata e dovrai usare quella estensibilità e mantenerla allo stesso modo di lo farai con Automake. In tal caso, potresti prendere in considerazione CMake poiché supporta la compilazione incrociata senza altrettante preoccupazioni per uscire dalla sandbox e funzionerà con / senza qualcosa come Scratchbox2 e si integra perfettamente con cose come OpenEmbedded.

C'è una ragione per cui molti, molti progetti stanno abbandonando qmake, Autotools, ecc. E passando a CMake. Finora, posso aspettarmi con chiarezza che un progetto basato su CMake cada in una situazione di compilazione incrociata o su un'installazione di VisualStudio o abbia bisogno solo di una piccola quantità di pulizia perché il progetto non ha tenuto conto delle parti solo per Windows o solo per OSX alla base di codice. Non posso davvero aspettarmi che da un progetto basato su SCons- e mi aspetto completamente che 1/3 o più progetti di Autotools abbiano sbagliato QUALCOSA che gli impedisce di costruirsi proprio su qualsiasi contesto tranne quello dell'host o uno di Scratchbox2.

Una distinzione importante deve essere fatta tra chi usa gli strumenti. Cmake è uno strumento che deve essere utilizzato dall'utente durante la creazione del software. Gli autotools sono usati per generare un tarball di distribuzione che può essere usato per costruire il software usando solo gli strumenti standard disponibili su qualsiasi sistema conforme a SuS. In altre parole, se si sta installando un software da un tarball creato utilizzando gli autotools, non si stanno utilizzando gli autotools . D'altra parte, se si sta installando un software che usa cmake, allora si sta utilizzando cmake e deve averlo installato per costruire il software.

La grande maggioranza degli utenti non ha bisogno di avere gli autotools installati sulla propria scatola. Storicamente, molta confusione è stata causata dal fatto che molti sviluppatori distribuiscono tarball non validi che costringono l'utente a eseguire autoconf per rigenerare lo script di configurazione, e questo è un errore di packaging. Una maggiore confusione è stata causata dal fatto che la maggior parte delle principali distribuzioni Linux installa più versioni degli autotools, quando non dovrebbero installarne nessuna per impostazione predefinita. Ancora più confusione è causata dagli sviluppatori che tentano di utilizzare un sistema di controllo della versione (ad esempio cvs, git, svn) per distribuire il loro software piuttosto che creare tarball.

Non si tratta di standard di codifica GNU.

I vantaggi attuali degli autotools - in particolare se usati con automake - sono che si integrano molto bene con la costruzione della distribuzione Linux.

Con cmake per esempio, è sempre "ho bisogno di -DCMAKE_CFLAGS o -DCMAKE_C_FLAGS di cui ho bisogno?" No, non è nemmeno, è "-DCMAKE_C_FLAGS_RELEASE". Oppure -DCMAKE_C_FLAGS_DEBUG. È confuso - in autoconf, è solo ./configure CFLAGS = "- O0 -ggdb3" e ce l'hai.

In integrazione con le infrastrutture di costruzione, gli scons hanno il problema che non è possibile utilizzare make %{?_smp_mflags}, _smp_mflagsin questo caso si tratta di una macro RPM che si espande approssimativamente alla potenza del sistema (l'amministratore può impostarlo). Le persone mettono qui cose come -jNCPUS nel loro ambiente. Con gli scons che non funzionano, quindi i pacchetti che usano gli scons possono essere distribuiti solo in serie in distro.

Ciò che è importante sapere sugli Autotools è che non sono un sistema di generazione generale: implementano gli standard di codifica GNU e nient'altro. Se vuoi creare un pacchetto che segua tutti gli standard GNU, gli Autotools sono uno strumento eccellente per il lavoro. Se non lo fai, allora dovresti usare Scons o CMake. (Ad esempio, vedi questa domanda .) Questo malinteso comune è da dove proviene la maggior parte della frustrazione con Autotools.

Mentre dal punto di vista degli sviluppatori, cmake è attualmente il più facile da usare, dal punto di vista dell'utente gli autotools hanno un grande vantaggio

gli autotools generano un singolo script di configurazione del file e tutti i file per generarlo vengono spediti con la distribuzione. è facile da capire e risolvere con l'aiuto di grep / sed / awk / vi. Confronta questo con Cmake in cui si trovano molti file in / usr / share / cmak * / Modules, che non possono essere riparati dall'utente a meno che non abbia accesso come amministratore.

Quindi, se qualcosa non funziona del tutto, di solito può essere facilmente "riparato" usando gli strumenti Unix standard (grep / sed / awk / vi ecc.) In un modo da mazza senza dover capire il sistema di compilazione.

Hai mai scavato nella tua directory di build di cmake per scoprire cosa non va? Rispetto al semplice shellscript che può essere letto dall'alto verso il basso, seguire i file Cmake generati per scoprire cosa sta succedendo è abbastanza difficile. Inoltre, con CMake, l'adattamento dei file FindFoo.cmake richiede non solo la conoscenza del linguaggio CMake, ma potrebbe anche richiedere i privilegi di superutente.