2009-12-18 13 views
41

Alcuni anni fa ho esaminato l'utilizzo di un sistema di build che non è Make e strumenti come CMake e SCons sembravano piuttosto primitivi. Mi piacerebbe scoprire se la situazione è migliorata. Così, secondo i seguenti criteri, qual è attualmente il miglior strumento di compilazione:Qual è attualmente il miglior sistema di build

  • indipendente dalla piattaforma: dovrebbe funzionare su Windows, Linux, Mac
  • lingua agnostico: avrebbe dovuto supporto integrato per le cose comuni, come la costruzione di C/C++ e altri lang statici. Immagino che non abbia bisogno di supportare la suite completa di autotools.
  • estensibile: Devo essere in grado di scrivere regole per generare file, come da renovturedText, latex, formati personalizzati, ecc. Non mi interessa davvero quale lingua devo scrivere le regole, ma preferirei un linguaggio reale piuttosto di un DSL.
  • Preferisco evitare di scrivere qualsiasi XML a mano, cosa che penso ad esempio per ant.
  • liberamente disponibili (preferibilmente open source)

Il termine "migliore" è un po 'soggettivo, ma credo che le risposte possono essere valutato oggettivamente dai criteri di cui sopra.

+0

Sono confuso. Dici "non è necessario supportare la suite completa di autotools". Questo significa che la tua domanda dovrebbe essere riformulata: "Qual è il prossimo miglior sistema di build dopo autoconf/automake?" –

+0

@William Pursell: No. Esprimo esplicitamente il requisito di supportare autoconf e automake, poiché è strettamente associato a Makefiles. –

+1

Non vedo nulla di sbagliato nella domanda originale o nella discussione che ne risulta. Dato che questa domanda è ora il principale motore di ricerca per "best build system", questa domanda dovrebbe essere riaperta. Potrei capire di chiuderlo se la discussione fosse stata effettivamente formulata, o se avesse effettivamente attratto lo spam, ma non è così. – user1110743

risposta

23

Avrei definitivamente votato per premake. Sebbene non sia potente quanto i suoi fratelli più grandi, il vantaggio principale è la semplicità assurda e la facilità d'uso. Rende la scrittura di multi-compilatore, codice multi-piattaforma un gioco da ragazzi e genera in modo nativo le soluzioni Visual Studio, i progetti XCode, Makefile e altri, senza bisogno di ulteriore lavoro.

+0

Sembra davvero carino. Detto questo, non sembra che supporti molto "out of the box"? –

+2

E Premake incorpora un interprete Lua, che è un linguaggio di scripting più potente di quello di CMake, secondo me. – Splo

+1

E non ha bisogno di scaricare un interprete Python per Windows come Scons o Waf. – Splo

-1

Final Builder è ben noto nel mondo di Windows

+3

Non pensavo di menzionare che dovrebbe essere gratuito (preferibilmente come nel discorso). Ho risolto la domanda. –

+0

Wow. Anche se sembra un programma solo per il download, usano icone che mi ricordano la scatola Vista che è impossibile capire. – Ken

0

Il progetto Il selenio si sta muovendo verso Rake, non perché è il migliore, ma perché gestisce più lingue leggermente migliori di tutti gli altri strumenti di compilazione ed è multipiattaforma (sviluppato in Ruby).

Tutti gli strumenti di costruzione hanno i loro problemi e le persone imparano a convivere con loro. Qualcosa che gira su JVM tende ad essere veramente buono per la creazione di applicazioni in modo Ant, Maven (So che la sua orribile), Ivy, Rake

6

CMake

CMake è estendibile, open-source del sistema che gestisce il processo di compilazione in un sistema operativo e in un modo indipendente dal compilatore .

+0

Ho scoperto che aveva problemi con Windows qualche anno fa. Sono riparati? –

+0

Ho iniziato a usarlo solo di recente e non ho riscontrato problemi. Considerando che MySQL lo usa per le sue build di Windows, non riesco a vederlo con grossi problemi. –

+2

CMake è molto meglio degli autotools ma utilizza ancora la sua DSL e vedo questo come un impedimento: devi investire nell'apprendimento di una nuova lingua. Per questo motivo, opterei per soluzioni come Waf (Python) o Rake (Ruby). – sorin

13

Quindi, a giudicare esclusivamente dai criteri indicati nella domanda, il sistema di compilazione che sembra il migliore è probabilmente waf - Python puro, fornisce supporto per C++ e altri linguaggi, generale, potente, non un DSL.


Tuttavia, dalla mia esperienza personale, preferisco CMake per i progetti C++. (Ho provato CMake, SCons e waf, e li ho graditi all'incirca in questo ordine). CMake è una soluzione generale, ma ha il supporto integrato per C++ che lo rende più carino di una soluzione più generica quando stai facendo C++.

Il modello di build di CMake per C++ è più dichiarativo e meno imperativo, e quindi, per me, più facile da usare.La sintassi del linguaggio CMake non è grande, ma una build dichiarativa con sintassi dispari batte una build imperativa in Python. Dei tre, anche CMake sembra avere il miglior supporto per cose "avanzate" come intestazioni precompilate. L'impostazione di intestazioni precompilate ha ridotto il mio tempo di ricostruzione di circa il 70%.

Altri vantaggi per CMake includono una documentazione decente e una comunità considerevole. Molte librerie open source hanno CMake per creare file in-tree o forniti dalla comunità di CMake. Ci sono progetti importanti che già usano CMake (mi viene in mente OGRE), e altri progetti importanti, come Boost e LLVM, sono in procinto di passare a CMake.

Parte del problema che ho riscontrato durante l'esperimento con i sistemi di build è che stavo cercando di creare un plug-in NPAPI su OS X, e risulta che sono stati impostati pochissimi sistemi di compilazione per dare a XCode la combinazione esatta di bandiere richieste fare così. CMake, riconoscendo che XCode è un bersaglio complesso e in movimento, fornisce un aggancio per l'impostazione manuale dei comandi nei progetti XCode generati (e Visual Studio, penso). Questo è molto intelligente per quanto mi riguarda.

Se si sta costruendo una libreria o un'applicazione può anche determinare quale sistema di generazione è il migliore. Boost utilizza ancora un sistema basato su jam, in parte perché fornisce il supporto più completo per la gestione dei tipi di build più complessi di "Debug" e "Release". La maggior parte delle librerie di boost ha cinque o sei versioni diverse, specialmente su Windows, che anticipano le persone che necessitano di librerie compatibili che si collegano a versioni diverse del CRT.

Non ho avuto problemi con CMake su Windows, ma ovviamente il tuo chilometraggio può variare. C'è una GUI decente per l'impostazione delle dipendenze di build, anche se è goffo da usare per le ricostruzioni. Fortunatamente c'è anche un client da riga di comando. Quello su cui mi sono accontentato finora è avere un Makefile wrapper sottile che invochi CMake da un objdir; CMake quindi genera Makefile nell'oggjdir e il Makefile originale li usa per creare la build. Ciò garantisce che le persone non invochino accidentalmente CMake dalla directory di origine e ingombrino il loro repository. Combinato con MinGW, questo "sandwich CMake" offre un'esperienza di costruzione cross-platform notevolmente coerente!

+0

Devo secondo questo. MacOSX e CMake non sono una soluzione se hai in mente la qualità (utilizzando strumenti come il supporto per l'internazionalizzazione). Un giorno verrà eseguita la migrazione del nostro sistema di build, attualmente funziona accettabile per un'app solo inglese più semplice – Lothar

+0

WAF è un codice abissale di bassa qualità. Impossibile estendere o persino leggere (mi chiedevo se fosse stato offuscato di proposito, ma qualunque cosa sia, sembra essere l'unica versione che esiste). Impossibile eseguire il debug o prevedere cosa farà. È uno scherzo di un programma per la progettazione di software, la codifica di Python completamente lenta e mista con la generazione di codice di runtime grottesca dove non era assolutamente necessario. Aaaand ... ha scritto un libro a riguardo * facepalm *. – wvxvw

12

Ovviamente ciò dipende dalle vostre priorità. Se si cerca principalmente la facilità d'uso, ci sono almeno due nuovi sistemi di build che si agganciano al filesystem per tracciare automaticamente le dipendenze in modo indipendente dal linguaggio.

Uno è tup:

http://gittup.org/tup/

e l'altro è fabbricare:

http://code.google.com/p/fabricate/

Quello che sembra essere le migliori prestazioni, portatile, e maturo (e quello Ho effettivamente usato) è tup. Il tizio che lo ha scritto mantiene anche una distro linux giocattolo in cui tutto è un sottomodulo git, e tutto (incluso il kernel) è compilato con tup. Da quello che ho letto sul sistema di compilazione del kernel, questo è un bel risultato.

Inoltre, Tup ripulisce vecchi obiettivi e altri cruft e può mantenere automaticamente i file .gitignore. Il risultato è che diventa banale sperimentare il layout e i nomi dei tuoi obiettivi, e puoi tranquillamente saltare tra le revisioni git senza ricostruire tutto. È scritto in C.

Se si conosce Haskell e siete alla ricerca di qualcosa per casi di utilizzo molto avanzati, controlla scossa:

http://community.haskell.org/~ndm/shake/

Update: Non ho provato, ma questo nuovo strumento "buildsome" anche ganci nel file system, ed è stato ispirato da tup, quindi è rilevante:

https://github.com/ElastiLotem/buildsome

+0

La mia comprensione è che la redo non si aggancia al filesystem, solo tup e fabricate do. –

2

Gradle sembra corrispondere a tutti i criteri di cui sopra.

È un sistema di costruzione che ha combinato il meglio di Maven e Ant. Per me, questo è il migliore.

-2

smooth build corrisponde alla maggior parte delle vostre esigenze.

  • indipendente dalla piattaforma: sì, è scritto in java
  • lingua agnostico: non supporta C/C++ t ancora, solo java ma è estendibile tramite plugin scritto in Java in modo da aggiungere un maggiore sostegno compilatori non è un problema
  • estensibile: sì, è possibile implementare la funzione regolare tramite il plugin java, è possibile anche creare una funzione uniforme definendola come espressione costruita con altre funzioni uniformi.
  • Io preferirei evitare di scrivere qualsiasi XML: non si vedrà una singola linea di esso in costruzione liscia
  • liberamente disponibili: sì, Apache 2 licenza

divulgazione: io sono l'autore di costruzione liscia.

Problemi correlati