Perché nessuno usa make per Java?

Quasi ogni progetto Java che ho visto utilizza Maven o Ant. Sono ottimi strumenti e penso che quasi tutti i progetti possano usarli. Ma che cosa mai è successo a fare ? È usato per una varietà di progetti non Java e può gestire facilmente Java. Sicuramente devi scaricare make.exe se usi Windows, ma anche Ant e Maven non vengono forniti con JDK.

C'è qualche difetto fondamentale con make quando usato con Java? È solo perché Ant e Maven sono scritti in Java?

Il problema fondamentale con Make e Java è che Make funziona sul presupposto che sia stata specificata una dipendenza, quindi una regola per risolverla.

Con C di base, che in genere "per convertire un file main.c in un file main.o, eseguire" cc main.c ".

Puoi farlo in Java, ma impari rapidamente qualcosa.

Principalmente che il compilatore javac è lento per l'avvio.

La differenza tra:

javac Main.java
javac This.java
javac That.java
javac Other.java

e

javac Main.java This.java That.java Other.java

è notte e giorno.

Esacerbalo con centinaia di classi e diventa insostenibile.

Quindi lo combini con il fatto che Java tende ad essere organizzato come gruppi di file in directory, vs C e altri che tendono verso una struttura più piatta. Make non ha molto supporto diretto per lavorare con gerarchie di file.

Inoltre, Make non è molto bravo a determinare quali file non sono aggiornati a livello di raccolta.

Con Ant, esaminerà e riassumerà tutti i file non aggiornati, quindi li compili in una volta sola. Make chiamerà semplicemente il compilatore Java su ogni singolo file. Avere make NOT per farlo richiede strumenti esterni sufficienti per dimostrare davvero che Make non è all'altezza del compito.

Ecco perché sono nate alternative come Ant e Maven.

Il venerabile makeprogramma gestisce ragionevolmente bene i linguaggi compilati separatamente come C e C ++. Compilate un modulo, lo usa #includeper estrarre il testo di altri file include e scrive un singolo file oggetto come output. Il compilatore è un sistema alla volta, con un passaggio di collegamento separato per associare i file oggetto in un file binario eseguibile.

Tuttavia, in Java, il compilatore deve effettivamente compilare altre classi con cui si importa import. Sebbene sarebbe possibile scrivere qualcosa che abbia generato tutte le dipendenze necessarie dal codice sorgente Java, in modo da makecostruire le classi nell'ordine corretto una alla volta, ciò non gestirà comunque casi come dipendenze circolari.

Il compilatore Java può anche essere più efficiente memorizzando nella cache i risultati compilati di altre classi mentre compilando ulteriori classi che dipendono dai risultati di quelli già compilati. Questo tipo di valutazione automatica delle dipendenze non è realmente possibile con il makesolo.

La domanda si basa su un presupposto errato: un numero non banale di sviluppatori fanno uso make. Vedi Java Build Tools: Ant vs. Maven . Per quanto riguarda il motivo per cui uno sviluppatore non avrebbe usato make: molti sviluppatori o non l'hanno mai usato makeo l'hanno usato e lo odiavano con un fuoco che brucia più caldo di mille soli. Come tali, usano strumenti alternativi.

In realtà, make può gestire la ricompilazione in un 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 ciascuno sono vere. Ante Mavenpotrebbe essere più adatto a Java che a creare, o come sottolinea Hank Gay, potrebbero non :)

Tuttavia, hai chiesto se è importante che Ant e Maven siano scritti in Java. Sebbene su StackOverflow non consideriamo tali pensieri (chiusi! Non relativi alla programmazione! Ecc.), DEL CORSO CHE È PARTE DELLA COSA. Su rotaie usiamo Rake, C dudes usa make e in Java usiamo Ant e Maven. Mentre è vero che gli sviluppatori Ant o Maven si prenderanno cura dello sviluppatore Java forse meglio di altri, c'è anche un'altra domanda: in cosa scrivi le attività Ant? Giava. Se sei uno sviluppatore Java, è una soluzione semplice.

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

Ant e in seguito Maven sono stati progettati per risolvere alcuni mal di testa causati da Make(mentre ne creano di nuovi nel processo). È solo evoluzione.

... Poco dopo, diversi progetti Java open source hanno capito che Ant poteva risolvere i problemi che avevano con Makefile ....

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

Sia che risolvano qualcosa o semplicemente creino un formato extra da imparare è un argomento soggettivo. La verità è che è praticamente la storia di ogni nuova invenzione: il creatore dice che risolve molti problemi e gli utenti originali dicono che sono virtù.

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

Immagino che una storia simile sarebbe con, rakeper 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 vasi di dipendenza.

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

1. Poiché Java comprende più piattaforme, i programmatori Java in generale non erano così abili negli strumenti Unix come i programmatori generalmente confinati in un ambiente Unix (ad esempio, programmatori C e Perl). Si noti che questo è IN GENERALE. Senza dubbio ci sono ed erano programmatori Java dotati di una profonda conoscenza di Unix.
2. Di conseguenza erano meno abili nel creare e non sapevano come usarlo in modo efficace.
3. Sebbene sia possibile scrivere un Makefile breve e semplice che compili Java in modo efficiente, è necessario prestare particolare attenzione 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 furono creati Ant e successivamente Maven.

In breve, sebbene make sia sicuramente utilizzabile per progetti Java, c'è stato un momento di opportunità per renderlo lo strumento di costruzione Java di fatto. Quel momento è passato.

Rendere gli script tendenzialmente dipendenti dalla piattaforma. Java dovrebbe essere indipendente dalla piattaforma. Pertanto, avere un sistema di compilazione che funziona solo su una piattaforma per una base multi-piattaforma è un problema.

Risposta breve: Perché make non va bene. Anche sul fronte C si vedono spuntare molte alternative.

Risposta lunga: makepresenta diversi difetti che la rendono a malapena adatta per la compilazione di C e non adatta per la compilazione di Java. Puoi forzarlo a compilare Java, se lo desideri, ma ti aspetti di incorrere in problemi, alcuni dei quali non dispongono di una soluzione o soluzione alternativa adatta. Eccone alcuni:

Risoluzione delle dipendenze

makesi aspetta intrinsecamente che i file abbiano una dipendenza simile ad un albero, in cui un file è l'output di crearne altri. Questo già si ritorce contro in C quando si tratta di file header. makerichiede makeche venga generato un file di inclusione specifico 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 spesso richiede di specificare il target come .PHONY. Fortunatamente, GCC supporta la generazione automatica di questi file.

In Java, la dipendenza può essere circolare e non esiste uno strumento per la generazione automatica delle dipendenze di classe in makeformato. antL' Dependattività può invece leggere direttamente il file di classe, determinare quali classi importa ed eliminare il file di classe se uno di essi non è aggiornato. Senza questo, qualsiasi dipendenza non banale potrebbe comportare la costrizione all'uso di build pulite ripetute, eliminando qualsiasi vantaggio derivante dall'uso di uno strumento di build.

Spazi nei nomi dei file

Mentre né Java né C incoraggiano l'uso di spazi nei nomi dei file del codice sorgente, in makequesto può essere un problema anche se gli spazi si trovano nel percorso del file. Considera, ad esempio, se il tuo codice sorgente esiste in C:\My Documents\My Code\program\src. Questo sarebbe abbastanza per rompersi make. Questo perché maketratta i nomi dei file come stringhe. anttratta i percorsi come oggetti speciali.

Scansione dei file per build

makerichiede l'impostazione esplicita di quali file devono essere creati per ogni destinazione. antconsente di specificare una cartella che deve essere scansionata automaticamente per i file di origine. 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 vera seccatura.

E il problema più grande con make:

make dipende da POSIX

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

Le regole di compilazione makesono essenzialmente piccoli bashscript. Anche se esiste una porta makeper Windows, affinché funzioni correttamente, deve essere abbinato a una porta di bash, che include un livello di emulazione POSIX per il file system.

Questo è disponibile in due varietà:

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

2. cygwinche fornisce un'emulazione POSIX completa. I programmi risultanti, tuttavia, tendono ancora a fare affidamento su quello strato di emulazione.

Per questo motivo, su Windows, lo strumento di compilazione standard non è nemmeno del maketutto, 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 "task", per manipolare file ed eseguire comandi in modo indipendente dalla piattaforma. È sufficientemente versatile che puoi effettivamente divertirti a costruire un programma C in Windows usando antpiuttosto che usando make.

E un ultimo minore:

Anche i programmi C non usano make nativamente

Inizialmente potresti non accorgertene, ma i programmi C generalmente non vengono spediti con a Makefile. Sono spediti con un CMakeLists.txt, o uno bashscript di configurazione, che genera l'effettivo Makefile. Al contrario, l'origine di un programma Java creato usando antviene fornito con uno antscript pre-costruito. A Makefileè un prodotto di altri strumenti - Ecco quanto makenon è adatto per essere uno strumento di costruzione da solo. antè autonomo e si occupa di tutto il necessario per il processo di compilazione Java, senza ulteriori requisiti o dipendenze.

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

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

"Gestione dei progetti con GNU Make" (disponibile sotto GFDL) contiene un capitolo completo dedicato all'utilizzo makecon i progetti Java.

Dato che contiene un lungo (e si spera giusto) elenco dei pro e dei contro dell'utilizzo di make anziché di altri strumenti che potresti voler dare un'occhiata lì. (vedi: http://oreilly.com/catalog/make3/book/ )

Ant è un miglioramento orientato alla configurazione XML rispetto a Makefile e Maven è un miglioramento dello strumento di creazione di dipendenza rispetto a Ant. Alcuni progetti usano tutti e tre. Penso che i progetti JDK usassero un mix di makefile e formica.

Un grande motivo è 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 nel proprio ambiente di sviluppo e consente ad altri strumenti come i server IDE e CI di integrare parti delle librerie ant / maven all'interno dell'infrastruttura di compilazione / distribuzione.

Una volta ho lavorato a un progetto Java che utilizzava gmake. Il mio ricordo è confuso ma IIRC ha avuto difficoltà a gestire la struttura della directory dei pacchetti che javac si aspetta. Ricordo anche che costruire file JAR era una seccatura a meno che tu non avessi qualcosa di banale.

ApacheAnt non è niente come Make. Make riguarda la descrizione delle dipendenze tra i file e come creare i file. La formica riguarda le dipendenze tra "compiti", ed è davvero un modo per incollare insieme gli script di compilazione.

ti può aiutare AntVsMake

Ant e Maven affrontano il grafico delle dipendenze di build e la sua gestione da una visione più "moderna" ... Ma come dice Oscar, hanno creato i loro problemi mentre cercavano di affrontare i vecchi problemi con make.

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

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

Oggi suppongo che qualsiasi sviluppatore Java con cui condivido il codice abbia installato Ant.