Perché nessuno usa make per Java?

Il venerabile programma make gestisce linguaggi compilati separatamente come C e C++ ragionevolmente bene. Si compila un modulo, utilizza #include per estrarre il testo di altri file di inclusione e scrive un singolo file oggetto come output. Il compilatore è molto un sistema one-at-a-time, con un passaggio di collegamento separato per associare i file oggetto in un binario eseguibile.

Tuttavia, in Java, il compilatore deve effettivamente compilare altre classi importate con import. Anche se sarebbe possibile scrivere qualcosa che ha generato tutte le dipendenze necessarie dal codice sorgente Java, in modo che make costruisca classi nell'ordine corretto una alla volta, questo non gestirebbe ancora casi come dipendenze circolari.

Il compilatore Java può anche essere più efficiente memorizzando nella cache i risultati compilati di altre classi mentre compila ulteriori classi che dipendono dai risultati di quelle già compilate. Questo tipo di valutazione automatica delle dipendenze non è realmente possibile con make da solo.

La domanda si basa su un'ipotesi errata: un numero non banale di sviluppatori fa usa make. Vedi Strumenti di compilazione Java: Ant vs. Maven. Per quanto riguarda il motivo per cui uno sviluppatore non userebbe make: molti sviluppatori non hanno mai usato make, o lo hanno usato e odiato con un fuoco che brucia più caldo di mille soli. Come tali, usano strumenti alternativi.

In realtà, make può gestire la ricompilazione in un unico comando di tutti i file java obsoleti. Cambia la prima riga se non vuoi compilare tutti i file nella directory o vuoi un ordine specifico...

JAVA_FILES:=$(wildcard *.java)
#
# the rest is independent of the directory
#
JAVA_CLASSES:=$(patsubst %.java,%.class,$(JAVA_FILES))

.PHONY: classes
LIST:=

classes: $(JAVA_CLASSES)
        if [ ! -z "$(LIST)" ] ; then \
                javac $(LIST) ; \
        fi

$(JAVA_CLASSES) : %.class : %.java
        $(eval LIST+=$$<)

Tutte le altre risposte sui meriti tecnici di ciascuna sono vere. Ant e Maven potrebbero essere più adatti a Java di make, o come sottolinea Hank Gay, potrebbero non :)

Tuttavia, hai chiesto se è importante che Ant e Maven siano scritti in Java. Anche se su StackOverflow non consideriamo tali pensieri (chiusi! non-programmazione-correlati! ecc.), OVVIAMENTE FA PARTE DELLA COSA. Su rails usiamo Rake, C dudes usa make, e in Java usiamo Ant e Maven. Mentre è vero che la Formica o Gli sviluppatori Maven si occuperanno dello sviluppatore Java forse meglio di altri, c'è anche un'altra domanda:in cosa scrivi le attività Ant? Java. Se sei uno sviluppatore Java, è una misura facile.

Quindi sì, parte di esso è usare strumenti scritti nella lingua che stai attrezzando.

Ant e più tardi Maven sono stati progettati per risolvere alcuni mal di testa causati da Make (durante la creazione di nuovi nel processo ) È solo evoluzione.

...Poco dopo, diversi progetti Java open source si sono resi conto che Ant poteva risolvere i problemi che avevano con i Makefile....

Da http://ant.apache.org/faq.html#history

Se risolvono qualcosa o semplicemente creano un formato extra per imparare è un argomento soggettivo. La verità è che praticamente la storia di ogni nuova invenzione: Il creatore dice che risolve un sacco di problemi e gli utenti originali dicono che quelle sono virtù.

Il vantaggio principale che ha, è la possibilità di integrarsi con java.

Immagino che una storia simile sarebbe con rake per esempio.

Uno dei principali problemi risolti da Maven (e dalle configurazioni Ant abilitate per Ivy) su make è la risoluzione automatica delle dipendenze e il download dei jar delle dipendenze.

Penso che la spiegazione più probabile sia che diversi fattori hanno scoraggiato l'uso di make all'interno della comunità Java in un periodo di tempo critico (la fine degli anni 1990):

1. Poiché Java comprende più piattaforme, i programmatori Java in generale non erano così abili negli strumenti Unix come lo erano i programmatori generalmente confinati in un ambiente Unix (ad esempio, programmatori C e Perl). Si noti che questo è IN GENERALE. Senza dubbio ci sono e sono stati dotati programmatori Java con un profondo comprensione di Unix.
2. Di conseguenza erano meno abili nel make e non sapevano come usare make in modo efficace.
3. Mentre è possibile scrivere un Makefile breve e semplice che compila Java in modo efficiente, è necessaria particolare attenzione per farlo in modo indipendente dalla piattaforma.
4. Di conseguenza c'era un appetito per uno strumento di costruzione intrinsecamente indipendente dalla piattaforma.
5. Fu in questo ambiente che Ant e in seguito Maven furono creati.

In breve, mentre fai sicuramente può essere utilizzato per progetti Java, c'è stato un momento di opportunità per renderlo lo strumento di creazione Java de facto. Quel momento è passato.

Gli script Make tendono ad essere intrinsecamente dipendenti dalla piattaforma. Java dovrebbe essere indipendente dalla piattaforma. Pertanto, avere un sistema di compilazione che funziona solo su una piattaforma per una base di origine multipiattaforma è un problema.

A meno che io non sia nessuno, il presupposto che nessuno stia (mis)usando make per java è sbagliato.

"Gestire i progetti con GNU Make" (disponibile sotto GFDL) contiene un capitolo completo dedicato all'utilizzo di make con i progetti java.

Poiché contiene una lunga (e si spera equa) lista dei pro e dei contro dell'uso di make invece di altri strumenti, potresti voler dare un'occhiata lì. (vedi: http://oreilly.com/catalog/make3/book/)

Ant è un miglioramento orientato alla configurazione XML rispetto ai Makefile e Maven è un miglioramento dello strumento di creazione delle dipendenze rispetto a Ant. Alcuni progetti utilizzano tutti e tre. Penso che i progetti JDK usassero un mix di makefile e ant.

Risposta breve: perché make non è buono. Anche sul fronte C si vedono molte alternative spuntando.

Risposta lunga: make ha diversi difetti che lo rendono a malapena adatto per la compilazione di C e inadatto per la compilazione di Java. Puoi forzarlo a compilare Java, se lo desideri, ma aspettarti di incorrere in problemi, alcuni dei quali non hanno una soluzione o una soluzione adeguata. Eccone alcuni:

Risoluzione delle dipendenze

make si aspetta intrinsecamente che i file abbiano un albero simile dipendenza l'una dall'altra, in cui un file è l'output di crearne diversi altri. Questo si ritorce già in C quando si tratta di file di intestazione. make richiede un file di inclusione specifico per make da generare per rappresentare la dipendenza di un file C dai suoi file di intestazione, quindi una modifica a quest'ultimo causerebbe la ricostruzione del precedente. Tuttavia, poiché il file C stesso non viene ricreato (semplicemente ricostruito), make richiede spesso di specificare la destinazione come .PHONY. Fortunatamente, GCC supporta la generazione di tali file automaticamente.

In Java, la dipendenza può essere circolare e non esiste uno strumento per la generazione automatica delle dipendenze di classe nel formato make. L'attività ant di Depend può, invece, leggere direttamente il file di classe, determinare quali classi importa ed eliminare il file di classe se qualcuno di essi non è aggiornato. Senza questo, qualsiasi dipendenza non banale potrebbe comportare l'obbligo di utilizzare build pulite ripetute, rimuovendo qualsiasi vantaggio dall'utilizzo di uno strumento di compilazione.

Spazi nei nomi dei file

Mentre né Java né C incoraggiano l'uso di spazi nei nomi dei file del codice sorgente, in make questo può essere un problema anche se gli spazi si trovano nel percorso del file. Si consideri, ad esempio, se il codice sorgente esiste in C:\My Documents\My Code\program\src. Questo sarebbe sufficiente per rompere make. Questo perché make considera i nomi dei file come stringhe. ant considera i percorsi come oggetti speciali.

Scansione dei file per la compilazione

make richiede l'impostazione esplicita di quali file devono essere creati per ogni destinazione. ant consente di specificare una cartella che deve essere scansionato automaticamente per i file sorgente. Può sembrare una comodità minore, ma considera che in Java ogni nuova classe richiede un nuovo file. L'aggiunta di file al progetto può diventare una grande seccatura veloce.

E il problema più grande con make:

Make è dipendente da POSIX

Il motto di Java è "compila una volta eseguito ovunque". Ma limitare quella compilazione ai sistemi basati su POSIX, in cui il supporto Java è in realtà il peggiore, non è l'intenzione.

Crea regole in make sono essenzialmente piccoli script bash. Anche se c'è una porta di make per Windows, affinché funzioni correttamente, deve essere fornita in bundle con una porta di bash, che include un livello di emulazione POSIX per il file system.

Questo è disponibile in due varietà:

1. MSYS che cerca di limitare la traduzione POSIX ai percorsi dei file, e può quindi avere trucchi spiacevoli quando si eseguono strumenti esterni non creati appositamente per questo.

2. cygwin quale fornisce un'emulazione POSIX completa. I programmi risultanti, tuttavia, tendono a fare ancora affidamento su quel livello di emulazione.

Per questo motivo, su Windows, lo strumento di compilazione standard non è nemmeno make, ma piuttosto MSBuild, che è anche uno strumento basato su XML, più vicino in linea di principio a ant.

Al contrario, ant è costruito in Java, può essere eseguito ovunque e contiene strumenti interni, chiamati "attività", per manipolare file ed eseguire comandi in modo indipendente dalla piattaforma. E sufficientemente versatile che si può effettivamente avere un tempo più facile costruire un programma C in Windows utilizzando ant rispetto all'utilizzo di make.

E un ultimo minore:

Anche i programmi C non usano make nativamente

Potresti non notarlo inizialmente, ma i programmi C generalmente non vengono forniti con un Makefile. Vengono forniti con uno script di configurazione CMakeLists.txt o bash, che genera l'effettivo Makefile. Al contrario, l'origine di un programma Java creato utilizzando ant viene fornito con uno script ant pre-costruito. A Makefile è un prodotto di altri strumenti - Questo è quanto make non è adatto per essere uno strumento di compilazione da solo. ant è autonomo e si occupa di tutto ciò di cui hai bisogno per il tuo processo di compilazione Java, senza requisiti o dipendenze aggiuntivi.

Quando si esegue ant su qualsiasi piattaforma, funziona solo(tm). Non puoi ottenerlo con make. È incredibilmente dipendente dalla piattaforma e dalla configurazione.

Una grande ragione è che sia Ant che Maven (e la maggior parte degli strumenti SCM, CI e IDE mirati a java) sono scritti in java da/per gli sviluppatori java. Ciò semplifica l'integrazione nell'ambiente di sviluppo e consente ad altri strumenti come i server IDE e CI di integrare porzioni delle librerie ant/maven all'interno dell'infrastruttura di compilazione/distribuzione.

C'era una volta ho lavorato su un progetto Java che utilizzava gmake. Il mio ricordo è confuso ma IIRC abbiamo avuto difficoltà a gestire la struttura delle directory dei pacchetti che javac si aspetta. Ricordo anche che la costruzione di file JAR era una seccatura a meno che non avessi qualcosa di banale.

Ant e Maven si avvicinano al grafico delle dipendenze di compilazione e alla sua gestione da una vista più "moderna"... Ma come dice Oscar, hanno creato i propri problemi durante il tentativo di affrontare i vecchi problemi con make.

Non ho mai usato GNU Make per progetti Java, ma ho usato jmk. Purtroppo non è stato aggiornato dal 2002.

Aveva alcune funzionalità specifiche di Java ma era abbastanza piccolo da includere nel tarball di origine senza aumentarne significativamente le dimensioni.

Al giorno d'oggi presumo che qualsiasi sviluppatore Java con cui condivido il codice abbia installato Ant.

ApacheAnt non è niente come Make. Make riguarda la descrizione delle dipendenze tra i file e come creare file. Ant riguarda le dipendenze tra "attività" ed è davvero più un modo per incollare insieme gli script di compilazione.

Può aiutare AntVsMake