Warum verwendet niemand make für Java?

Nahezu jedes Java-Projekt, das ich gesehen habe, verwendet entweder Maven oder Ant. Sie sind gute Werkzeuge und ich denke, fast jedes Projekt kann sie verwenden. Aber was auch immer passiert zu machen ? Es wird für eine Vielzahl von Nicht-Java-Projekten verwendet und kann problemlos mit Java umgehen. Natürlich müssen Sie make.exe herunterladen, wenn Sie Windows verwenden, aber Ant und Maven werden auch nicht mit dem JDK geliefert.

Gibt es einen grundlegenden Fehler bei make, wenn es mit Java verwendet wird? Liegt es nur daran, dass Ant und Maven in Java geschrieben sind?

Das grundlegende Problem bei Make und Java besteht darin, dass Make unter der Voraussetzung funktioniert, dass Sie eine Abhängigkeit und anschließend eine Regel zum Auflösen dieser Abhängigkeit angegeben haben.

Führen Sie mit Basic C normalerweise "cc main.c" aus, um "eine main.c-Datei in eine main.o-Datei zu konvertieren".

Sie können das in Java tun, aber Sie lernen schnell etwas.

Meistens startet der Javac-Compiler nur langsam.

Der Unterschied zwischen:

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

und

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

ist Tag und Nacht.

Verschärfen Sie das mit Hunderten von Klassen, und es wird einfach unhaltbar.

Dann kombinieren Sie dies mit der Tatsache, dass Java in der Regel als Dateigruppen in Verzeichnissen organisiert ist, im Vergleich zu C und anderen, die zu einer flacheren Struktur tendieren. Make hat nicht viel direkte Unterstützung für die Arbeit mit Hierarchien von Dateien.

Make ist auch nicht sehr gut darin festzustellen, welche Dateien auf Sammlungsebene veraltet sind.

Mit Ant werden alle veralteten Dateien durchlaufen und zusammengefasst und anschließend auf einmal kompiliert. Make ruft einfach den Java-Compiler für jede einzelne Datei auf. Damit make NOT dies nicht tut, sind genügend externe Tools erforderlich, um wirklich zu zeigen, dass Make der Aufgabe nicht ganz gewachsen ist.

Deshalb sind Alternativen wie Ant und Maven aufgetaucht.

Das ehrwürdige makeProgramm verarbeitet separat kompilierte Sprachen wie C und C ++ ziemlich gut. Sie kompilieren ein Modul, das es verwendet#include , um den Text anderer Include-Dateien abzurufen, und schreiben eine einzelne Objektdatei als Ausgabe. Der Compiler ist in hohem Maße ein einzelnes System mit einem separaten Verknüpfungsschritt, um die Objektdateien in eine ausführbare Binärdatei zu binden.

In Java muss der Compiler jedoch tatsächlich andere Klassen kompilieren , mit denen Sie importieren import. Obwohl es möglich wäre, etwas zu schreiben, das alle erforderlichen Abhängigkeiten aus dem Java-Quellcode generiert, sodass makedie Klassen einzeln in der richtigen Reihenfolge erstellt werden, werden Fälle wie zirkuläre Abhängigkeiten immer noch nicht behandelt.

Der Java-Compiler kann auch effizienter sein, indem die kompilierten Ergebnisse anderer Klassen zwischengespeichert werden, während weitere Klassen kompiliert werden, die von den Ergebnissen bereits kompilierter Klassen abhängen. Diese Art der automatischen Abhängigkeitsbewertung ist makeallein nicht wirklich möglich .

Die Frage beruht auf einer falschen Annahme: eine nicht-triviale Zahl der Entwickler tun Einsatz make. Siehe Java Build Tools: Ant vs. Maven . Warum ein Entwickler nicht verwenden würde make: Viele Entwickler haben es entweder nie verwendet makeoder es verwendet und hassten es mit einem Feuer, das heißer als tausend Sonnen brennt. Als solche verwenden sie alternative Werkzeuge.

Tatsächlich kann make die Neukompilierung aller veralteten Java-Dateien in einem Befehl durchführen. Ändern Sie die erste Zeile, wenn Sie nicht alle Dateien im Verzeichnis kompilieren möchten oder eine bestimmte Reihenfolge wünschen ...

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+=$$<)

Alle anderen Antworten über die technischen Vorzüge der einzelnen sind wahr. Antund sind Mavenmöglicherweise besser für Java geeignet als make, oder wie Hank Gay betont, möglicherweise nicht :)

Sie haben jedoch gefragt, ob es wichtig ist, dass Ant und Maven in Java geschrieben sind. Obwohl wir bei StackOverflow solche Gedanken nicht berücksichtigen (geschlossen! Nicht programmierbezogen! Usw.), ist das natürlich ein Teil der Sache. Auf Schienen verwenden wir Rake, C-Typen make und in Java Ant und Maven. Es stimmt zwar, dass die Ant- oder Maven-Entwickler den Java-Entwickler vielleicht besser betreuen als andere, aber es gibt noch eine andere Frage: In was schreiben Sie Ant-Aufgaben? Java. Wenn Sie ein Java-Entwickler sind, ist das eine einfache Lösung.

Ein Teil davon besteht darin, Werkzeuge zu verwenden, die in der Sprache geschrieben sind, in der Sie arbeiten.

Ant und später Maven wurden entwickelt, um einige Kopfschmerzen zu lösen, die durch Make(während des Erstellens neuer Kopfschmerzen) verursacht werden. Es ist nur Evolution.

... Bald darauf erkannten mehrere Open-Source-Java-Projekte, dass Ant die Probleme lösen konnte, die sie mit Makefiles hatten ...

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

Ob sie etwas lösen oder nur ein zusätzliches Lernformat erstellen, ist ein subjektives Thema. Die Wahrheit ist, dass dies so ziemlich die Geschichte jeder neuen Erfindung ist: Der Schöpfer sagt, dass sie viele Probleme löst, und die ursprünglichen Benutzer sagen, dass dies Tugenden sind.

Der Hauptvorteil ist die Möglichkeit, sich in Java zu integrieren.

Ich denke, eine ähnliche Geschichte wäre rakezum Beispiel mit.

Eines der Hauptprobleme, das von Maven (und Ivy-fähigen Ant-Setups) über make gelöst wurde, ist die automatisierte Auflösung von Abhängigkeiten und das Herunterladen Ihrer Abhängigkeitsgläser.

Ich denke, die wahrscheinlichste Erklärung ist, dass mehrere Faktoren die Verwendung von make in der Java-Community in einem kritischen Zeitraum (Ende der neunziger Jahre) behindert haben:

1. Da Java mehrere Plattformen umfasst, waren Java-Programmierer im Allgemeinen mit Unix-Tools nicht so vertraut wie Programmierer, die im Allgemeinen auf eine Unix-Umgebung beschränkt waren (z. B. C- und Perl-Programmierer). Beachten Sie, dass dies ALLGEMEIN ist. Ohne Zweifel gibt und gab es begabte Java-Programmierer mit einem tiefen Verständnis von Unix.
2. Folglich waren sie weniger geschickt in make und wussten nicht, wie man make effektiv einsetzt.
3. Während es möglich ist, ein kurzes und einfaches Makefile zu schreiben, das Java effizient kompiliert, ist besondere Sorgfalt erforderlich, um dies plattformunabhängig zu tun.
4. Infolgedessen bestand Appetit auf ein an sich plattformunabhängiges Build-Tool.
5. In dieser Umgebung wurden Ant und später Maven geschaffen.

Kurz gesagt, während make mit Sicherheit für Java-Projekte verwendet werden kann, gab es einen Moment der Gelegenheit, es zum De-facto-Java-Build-Tool zu machen. Dieser Moment ist vergangen.

Make-Skripte sind in der Regel plattformabhängig. Java soll plattformunabhängig sein. Daher ist ein Build-System, das nur auf einer Plattform für eine Quellplattform mit mehreren Plattformen funktioniert, ein Problem.

Kurze Antwort: Weil makees nicht gut ist. Sogar an der C-Front tauchen viele Alternativen auf.

Lange Antwort: Es makegibt mehrere Fehler, die es kaum zum Kompilieren von C und überhaupt nicht zum Kompilieren von Java geeignet machen. Sie können es erzwingen, Java zu kompilieren, wenn Sie möchten, aber erwarten, dass Probleme auftreten, von denen einige keine geeignete Lösung oder Problemumgehung haben. Hier sind ein paar:

Abhängigkeitsauflösung

makeerwartet von Natur aus, dass Dateien eine baumartige Abhängigkeit voneinander haben, wobei eine Datei die Ausgabe der Erstellung mehrerer anderer Dateien ist. Dies schlägt in C bereits fehl, wenn es sich um Header-Dateien handelt. makeerfordert, dass eine makespezifische Include-Datei generiert wird, um die Abhängigkeit einer C-Datei von ihren Header-Dateien darzustellen, sodass eine Änderung an letzterer dazu führen würde, dass die vorherige Datei neu erstellt wird. Da die C-Datei selbst jedoch nicht neu erstellt (lediglich neu erstellt) wird, muss für make häufig das Ziel als angegeben werden .PHONY. Glücklicherweise unterstützt GCC das automatische Generieren dieser Dateien.

In Java kann die Abhängigkeit zirkulär sein, und es gibt kein Tool zum automatischen Generieren von Klassenabhängigkeiten im makeFormat. antDie DependAufgabe kann stattdessen die Klassendatei direkt lesen, bestimmen, welche Klassen importiert werden, und die Klassendatei löschen, wenn eine davon veraltet ist. Ohne dies kann eine nicht triviale Abhängigkeit dazu führen, dass Sie gezwungen sind, wiederholte saubere Builds zu verwenden, wodurch der Vorteil der Verwendung eines Build-Tools entfällt.

Leerzeichen in Dateinamen

Während weder Java noch C die Verwendung von Leerzeichen in Ihren Quellcodedateinamen fördern, makekann dies auch dann problematisch sein, wenn sich die Leerzeichen im Dateipfad befinden. Überlegen Sie beispielsweise, ob Ihr Quellcode in vorhanden ist C:\My Documents\My Code\program\src. Dies würde ausreichen, um zu brechen make. Dies liegt daran, dass makeDateinamen als Zeichenfolgen behandelt werden. antbehandelt Pfade als spezielle Objekte.

Scannen von Dateien zum Erstellen

makeerfordert die explizite Einstellung, welche Dateien für jedes Ziel erstellt werden sollen. antErmöglicht die Angabe eines Ordners, der automatisch nach Quelldateien durchsucht werden soll. Es mag wie eine kleine Annehmlichkeit erscheinen, aber bedenken Sie, dass in Java jede neue Klasse eine neue Datei benötigt. Das Hinzufügen von Dateien zum Projekt kann schnell zu einem großen Problem werden.

Und das größte Problem mit make:

make ist POSIX-abhängig

Javas Motto lautet "Kompilieren, einmal überall ausgeführt". Es ist jedoch nicht beabsichtigt, diese Kompilierung auf POSIX-basierte Systeme zu beschränken, bei denen die Java-Unterstützung tatsächlich am schlechtesten ist.

Build-Regeln makesind im Wesentlichen kleine bashSkripte. Obwohl es einen Port von makeWindows gibt, muss dieser mit einem Port von Windows gebündelt werden bash, der eine POSIX-Emulationsschicht für das Dateisystem enthält , damit er ordnungsgemäß funktioniert.

Dies gibt es in zwei Varianten:

1. MSYS Dies versucht, die POSIX-Übersetzung auf Dateipfade zu beschränken, und kann daher unangenehme Fallstricke verursachen, wenn externe Tools ausgeführt werden, die nicht speziell dafür entwickelt wurden.

2. cygwinDies bietet eine vollständige POSIX-Emulation. Die resultierenden Programme neigen jedoch dazu, sich immer noch auf diese Emulationsschicht zu verlassen.

Aus diesem Grund ist das Standard-Build-Tool unter Windows makeüberhaupt nicht vorhanden, sondern MSBuildim Prinzip eher ein XML-basiertes Tool ant.

Im Gegensatz dazu antist es in Java erstellt, kann überall ausgeführt werden und enthält interne Tools, sogenannte "Tasks", mit denen Dateien bearbeitet und Befehle plattformunabhängig ausgeführt werden können. Es ist so vielseitig, dass es für Sie tatsächlich einfacher ist, ein C-Programm unter Windows zu erstellen antals mit make.

Und noch eine letzte Kleinigkeit:

Selbst C-Programme verwenden make nicht nativ

Möglicherweise bemerken Sie dies zunächst nicht, aber C-Programme werden im Allgemeinen nicht mit a ausgeliefert Makefile. Sie werden mit einem CMakeLists.txtoder einem bashKonfigurationsskript geliefert, das das tatsächliche generiert Makefile. Im Gegensatz dazu wird die Quelle eines Java-Programms, das mit erstellt wurde ant, mit einem antvorgefertigten Skript ausgeliefert. A Makefileist ein Produkt anderer Tools - So viel makeist ungeeignet, um ein eigenständiges Build-Tool zu sein. antist eigenständig und behandelt alles, was Sie für Ihren Java-Erstellungsprozess benötigen, ohne zusätzliche Anforderungen oder Abhängigkeiten.

Wenn Sie antauf einer beliebigen Plattform ausgeführt werden, funktioniert dies nur (tm). Das kann man nicht bekommen make. Es ist unglaublich plattform- und konfigurationsabhängig.

Wenn ich niemand bin, ist die Annahme, dass niemand make for java (falsch) benutzt, falsch.

"Verwalten von Projekten mit GNU Make" (verfügbar unter GFDL) enthält ein vollständiges Kapitel zur Verwendung makemit Java-Projekten.

Da es eine lange (und hoffentlich faire) Liste der Vor- und Nachteile der Verwendung von make anstelle anderer Tools enthält, sollten Sie dort einen Blick darauf werfen. (siehe: http://oreilly.com/catalog/make3/book/ )

Ant ist eine auf die XML-Konfiguration ausgerichtete Verbesserung gegenüber Makefiles und Maven ist eine Verbesserung des Abhängigkeitserstellungstools gegenüber Ant. Einige Projekte verwenden alle drei. Ich denke, die JDK-Projekte verwendeten früher eine Mischung aus Makefiles und Ant.

Ein wichtiger Grund ist, dass sowohl Ant als auch Maven (und die meisten auf Java ausgerichteten SCM-, CI- und IDE-Tools) von / für Java-Entwickler in Java geschrieben wurden. Dies vereinfacht die Integration in Ihre Entwicklungsumgebung und ermöglicht anderen Tools wie den IDE- und CI-Servern, Teile der Ant / Maven-Bibliotheken in die Build- / Bereitstellungsinfrastruktur zu integrieren.

Es war einmal ein Java-Projekt, das gmake verwendete. Meine Erinnerung ist verschwommen, aber beim IIRC fiel es uns schwer, mit der Paketverzeichnisstruktur umzugehen, die javac erwartet. Ich erinnere mich auch, dass das Erstellen von JAR-Dateien ein Problem war, es sei denn, Sie hatten etwas Triviales.

ApacheAnt ist nichts wie Make. Bei Make geht es darum, Abhängigkeiten zwischen Dateien zu beschreiben und wie Dateien erstellt werden. Ant handelt von Abhängigkeiten zwischen "Aufgaben" und ist eher eine Möglichkeit, Build-Skripte zusammenzukleben.

es kann Ihnen helfen, AntVsMake

Ant und Maven nähern sich dem Build-Abhängigkeitsgraphen und dessen Verwaltung aus einer "moderneren" Sicht ... Aber wie Oscar sagt, haben sie ihre eigenen Probleme erstellt, während sie versucht haben, die alten Probleme mit make anzugehen.

Ich habe GNU Make nie für Java-Projekte verwendet, aber ich habe jmk verwendet . Leider wurde es seit 2002 nicht mehr aktualisiert.

Es hatte einige Java-spezifische Funktionen, war aber klein genug, um in Ihren Quell-Tarball aufgenommen zu werden, ohne seine Größe wesentlich zu erhöhen.

Heutzutage gehe ich einfach davon aus, dass jeder Java-Entwickler, mit dem ich Code teile, Ant installiert hat.