Qual è la vera utilità di make e ant?

Question

Mentre sto sviluppando in C/C++ e Java, faccio semplicemente uno script compile.bat che fa tutto, per me va bene. Perché dovrei usare make e perché dovrei usare formica?

Answer 1

Supponiamo di avere 1000 file sorgente e di modificarne solo uno. Con il tuo script .bat dovrai ricompilare il lotto, facendoti ricompilare solo quello che è cambiato. Questo può far risparmiare parecchio tempo (leggere ore su un grande progetto).

Ancora meglio, se si modifica uno dei file di intestazione, make ricompilerà solo i file di origine che utilizzano tale intestazione.

Queste sono le due caratteristiche principali che hanno significato che la marca e la sua progenie sono utilizzate per lo sviluppo di software serio con linguaggi compilati.

Answer 2

Per prima cosa, make e ant tengono traccia di quali file sono già stati compilati, quindi non ripristina il lavoro se non è necessario.

Answer 3

Con un file di build, è possibile automatizzare qualcosa di più della semplice compilazione del codice; puoi eseguire unit test, raccogliere metriche, artefatti di build del pacchetto per la distribuzione e altro ancora.

Un vantaggio, di sorta, di Ant è che ha ispirato strumenti per altre piattaforme: NAnt per .NET, Phing per PHP. Fanno le stesse cose e lavorano allo stesso modo.

Answer 4

Finché si sviluppa da soli sotto Windows: soddisfare te stesso.

Ma se inizi a sviluppare con altri Ant e Make sono uno standard per descrivere come viene costruita la tua app.

Answer 5

Ci possono essere diverse ragioni: - perché non sei l'unico in progetto - perché qualcuno dovrà preoccuparsi del script di build quando avete lasciato - perché uno script compile.bat non è indipendente dalla piattaforma - perché la politica del progetto definisce la tecnologia di costruzione, ad es per l'intera impresa

Recentemente ho letto un divertente article about build tools. Per te solo la prima parte può essere di qualsiasi interesse (prima che inizi il battere del maven)

Answer 6

Ottieni una certa neutralità della piattaforma (come posso eseguire il tuo script batch sul mio linux-box). Ma più importante: gli strumenti di costruzione hanno il supporto per la risoluzione delle dipendenze. Gli script mancano di questo e devono costruirlo da soli.

Supponiamo di avere obiettivi A, B e C. B e C entrambi dipendono da A. In uno script chiamano la subroutine A. Se ora crei un nuovo target D, che dipende da B e C, allora dovrai eseguire A due volte. Gli strumenti di compilazione lo riconoscono ed eseguono A una sola volta.

Poiché questa situazione è tipica dell'attività che comporta la compilazione, la creazione di una distribuzione, un test, una documentazione di costruzione, ecc. Gli strumenti di compilazione sono utili per lo sviluppo del software.

Answer 7

Sarebbe possibile utilizzare un file .bat - o bash o un altro sapore di script di shell - per fare tutto ciò che Ant può fare, io credo. Ma è molto più facile fare molte cose in Ant ...

• creare/spostare/cancellare i file e le directory
• applicare il filtro gettoni
• unità di eseguire test
• pacchetto di un barattolo, zip, o la guerra propriamente

Molti progetti hanno bisogno di fare queste cose, oltre alla compilazione, quando costruiscono.

anche Ant è indipendente dalla piattaforma, in modo da poter collaborare con coloro che utilizzano altri sistemi operativi.

Ma perché fermarsi a Ant? Apache Maven offre funzionalità ancora più interessanti.

Answer 8

Marca e Ant realmente entrano in loro propri quando viene utilizzato con sistemi di compilazione automatici o l'integrazione continua.

I requisiti per build di produzione, build di test e build di sviluppo sono spesso diversi e, in un team composto da più persone, diversi sviluppatori impostano i loro ambienti di sviluppo in modi diversi.

Avere un processo di compilazione definitivo risolve i problemi "Works on My Machine" (WOMM) che si presentano ogni volta che l'applicazione deve essere costruita su una macchina diversa da quella su cui è stata sviluppata. È l'arbitro ultimo quando uno sviluppatore controlla il codice che non funziona sulla macchina di un altro sviluppatore. Se il processo di compilazione non produce software funzionante, il primo check-in dello sviluppatore è stato interrotto. Se produce software funzionante, l'ambiente di sviluppo del secondo sviluppatore è danneggiato, a meno che non sia provato diversamente.