Pourquoi personne n'utilise make for Java?

Le vénérable programme make gère raisonnablement bien les langages compilés séparément comme C et C++. Vous compilez un module, il utilise #include pour extraire le texte d'autres fichiers include et écrit un seul fichier objet en sortie. Le compilateur est un système unique à la fois, avec une étape de liaison séparée pour lier les fichiers objets dans un binaire exécutable.

Cependant, en Java, le compilateur a fait compiler autres classes que vous importez avec import. Bien qu'il serait possible d'écrire quelque chose qui a généré toutes les dépendances nécessaires à partir du code source Java, de sorte que make construirait des classes dans le bon ordre une à la fois, cela ne gérerait toujours pas les cas tels que les dépendances circulaires.

Le compilateur Java peut également être plus efficace en mettant en cache les résultats compilés d'autres classes tout en compilant d'autres classes qui dépendent des résultats de celles déjà compilées. Ce type d'évaluation automatique des dépendances n'est pas vraiment possible avec make seul.

, La question est basée sur une hypothèse erronée: un nombre non négligeable de développeurs do utiliser make. VoirOutils de construction Java: Ant vs Maven . Quant à savoir pourquoi un développeur n'utiliserait pas make: de nombreux développeurs n'ont jamais utilisé make, ou l'ont utilisé et l'ont détesté avec un feu qui brûle plus chaud que mille soleils. En tant que tels, ils utilisent des outils alternatifs.

En fait, make peut gérer la recompilation en une seule commande de tous les fichiers java obsolètes. Modifiez la première ligne si vous ne souhaitez pas compiler tous les fichiers du répertoire ou si vous souhaitez un ordre spécifique...

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

Toutes les autres réponses sur les mérites techniques de chacune sont vraies. Ant et Maven peuvent être mieux adaptés à Java que make, ou comme le souligne Hank Gay, ils peuvent ne pas:)

Cependant, vous avez demandé s'il importait que Ant et Maven soient écrits en Java. Bien que sur StackOverflow nous ne considérons pas de telles pensées (fermé! non lié à la programmation! etc.), BIEN SÛR QUE CELA FAIT PARTIE DE LA CHOSE. Sur rails, nous utilisons Rake, C dudes utilise make, et en Java, nous utilisons Ant et Maven. Alors qu'il est vrai que la Fourmi ou Les développeurs Maven s'occuperont du développeur Java peut-être mieux que les autres, il y a aussi une autre question: dans quoi écrivez-vous des tâches Ant? Java. Si vous êtes un développeur Java, c'est un ajustement facile.

Donc oui, une partie consiste à utiliser des outils écrits dans la langue que vous utilisez.

Ant et plus tard Maven ont été conçus pour résoudre certains maux de tête causés par Make ( tout en en créant de nouveaux dans le processus ) C'est juste de l'évolution.

...Peu de temps après, plusieurs projets Java open source ont réalisé que Ant pouvait résoudre les problèmes qu'ils avaient avec Makefiles....

À Partir de http://ant.apache.org/faq.html#history

Qu'ils résolvent quelque chose ou qu'ils créent simplement un format supplémentaire pour apprendre est un sujet subjectif. La vérité est que l' à peu près l'histoire de chaque nouvelle invention: Le créateur dit qu'il résout beaucoup de problèmes et les utilisateurs d'origine disent que ce sont des vertus.

Le principal avantage qu'il a, est la possibilité d'intégrer avec java.

Je suppose qu'une histoire similaire serait avec rake par exemple.

L'un des principaux problèmes résolus par Maven (et les configurations Ant compatibles Ivy) sur make est la résolution automatisée des dépendances et le téléchargement de vos fichiers jar de dépendances.

Je pense que l'explication la plus probable est que plusieurs facteurs ont découragé l'utilisation de make au sein de la communauté Java dans une période critique (la fin des années 1990):

1. Parce que Java englobe plusieurs plates-formes, les programmeurs Java en général n'étaient pas aussi aptes aux outils Unix que les programmeurs généralement confinés à un environnement Unix (par exemple, les programmeurs C et Perl). À noter que c'est EN GÉNÉRAL. Sans aucun doute il y a et étaient doués programmeurs Java avec une profondeur compréhension d'Unix.
2. Par conséquent, ils étaient moins habiles à faire et ne savaient pas comment utiliser efficacement faire.
3. Bien qu'il soit possible d'écrire un Makefile court et simple qui compile Java efficacement, un soin supplémentaire est nécessaire pour le faire de manière indépendante de la plate-forme.
4. Par conséquent, il y avait un appétit pour un outil de construction intrinsèquement indépendant de la plate-forme.
5. C'est dans cet environnement que Ant et plus tard Maven ont été créés.

En bref, alors que faire très certainement peut être utilisé pour les projets Java, il y avait un moment d'opportunité pour en faire l'outil de construction Java de facto. Ce moment est passé.

Les scripts ont tendance à dépendre intrinsèquement de la plate-forme. Java est censé être indépendant de la plateforme. Par conséquent, avoir un système de construction qui ne fonctionne que sur une seule plate-forme pour une base de source multi-plate-forme est un problème.

Sauf si je ne suis personne, l'hypothèse que personne n'utilise (mal)make pour java est fausse.

"Gérer les projets avec GNU Make" (disponible sous GFDL) contient un chapitre complet dédié à l'utilisation de make avec des projets java.

Comme il contient une longue liste (et espérons-le juste) des avantages et des inconvénients de l'utilisation de make au lieu d'autres outils, vous voudrez peut-être y jeter un coup d'œil. (voir: http://oreilly.com/catalog/make3/book/)

Ant est une amélioration orientée configuration XML sur Makefiles et Maven est une amélioration de l'outil de construction de dépendance sur Ant. Certains projets utilisent les trois. Je pense que les projets JDK utilisaient un mélange de makefiles et de ant.

Réponse Courte: Parce que make n'est pas bon. Même sur le front C, vous voyez de nombreuses alternatives apparaître.

Réponse longue: make a plusieurs défauts qui le rendent à peine adapté à la compilation C, et inadapté du tout à la compilation Java. Vous pouvez le forcer à compiler Java, si vous le souhaitez, mais vous attendez à rencontrer des problèmes, dont certains n'ont pas de solution ou de solution de contournement appropriée. En voici quelques-uns:

Résolution de dépendance

make s'attend intrinsèquement à ce que les fichiers aient une arborescence dépendance les uns des autres, dans lequel un fichier est la sortie de la construction de plusieurs autres. Cela se retourne déjà en C lorsque vous traitez des fichiers d'en-tête. make nécessite qu'un fichier d'inclusion spécifique à make soit généré pour représenter la dépendance d'un fichier C sur ses fichiers d'en-tête, donc une modification de ce dernier entraînerait la reconstruction du précédent. Cependant, comme le fichier C lui-même n'est pas recréé (simplement reconstruit), make nécessite souvent de spécifier la cible comme .PHONY. Heureusement, GCC prend en charge la génération de ces fichiers automatiquement.

En Java, la dépendance peut être circulaire, et il n'y a pas d'outil pour générer automatiquement des dépendances de classe au format make. La tâche ant de Depend peut, à la place, lire directement le fichier de classe, déterminer quelles classes elle importe et supprimer le fichier de classe si l'une d'entre elles est obsolète. Sans cela, toute dépendance non triviale peut vous obliger à utiliser des builds propres répétés, supprimant tout avantage d'utiliser un outil de build.

Espaces dans les noms de fichiers

Tandis que ni Java ni C n'encouragent l'utilisation d'espaces dans vos noms de fichiers de code source, dans make cela peut être un problème même si les espaces sont dans le chemin du fichier. Considérons, par exemple, si votre code source existe dans C:\My Documents\My Code\program\src. Ce serait suffisant pour casser make. En effet, make traite les noms de fichiers comme des chaînes. ant traite les chemins comme des objets spéciaux.

Analyse des fichiers pour la construction

make nécessite de définir explicitement les fichiers à créer pour chaque cible. ant permet de spécifier un dossier qui doit être analysé automatiquement pour les fichiers source. Cela peut sembler une commodité mineure, mais considérez qu'en Java chaque nouvelle classe nécessite un nouveau fichier. Ajouter des fichiers au projet peut rapidement devenir un gros problème.

Et le plus gros problème avec make:

Make dépend de POSIX

Java telle est la devise de "compiler une fois, exécuter partout". Mais restreindre cette compilation aux systèmes basés sur POSIX, dans lesquels le support Java est en fait le pire, n'est pas l'intention.

Règles de construction dans make sont essentiellement de petits scripts bash. Même s'il existe un port de make vers Windows, pour qu'il fonctionne correctement, il doit être livré avec un port de bash, qui inclut une couche d'émulation POSIX pour le système de fichiers.

Il existe deux variétés:

1. MSYS qui essaie de limiter la traduction POSIX aux chemins de fichiers, et peut donc avoir des erreurs désagréables lors de l'exécution d'outils externes non spécialement conçus pour cela.

2. cygwin qui fournit une émulation POSIX complète. Les programmes résultants, cependant, ont tendance à toujours s'appuyer sur cette couche d'émulation.

Pour cette raison, sous Windows, l'outil de construction standard n'est même pas make du tout, mais plutôt MSBuild, qui est également un outil basé sur XML, plus proche en principe de ant.

En revanche, ant est construit en Java, peut s'exécuter partout et contient des outils internes, appelés "tâches", pour manipuler des fichiers et exécuter des commandes de manière indépendante de la plate-forme. C'est suffisamment polyvalent pour que vous puissiez avoir plus de facilité à créer un programme C dans Windows en utilisant ant qu'en utilisant make.

Et un dernier mineur:

Même les programmes C n'utilisent pas make nativement

Vous ne le remarquerez peut-être pas initialement, mais les programmes C ne sont généralement pas livrés avec un Makefile. Ils sont livrés avec un CMakeLists.txt, ou un script de configuration bash, qui génère le Makefile réel. En revanche, la source d'un programme Java construit à l'aide de {[7] } est livrée avec un script ant pré-construit. Un Makefile est un produit d'autres outils - C'est à quel point make ne convient pas pour être un outil de construction à lui seul. ant est autonome et traite de tout ce dont vous avez besoin pour votre processus de construction Java, sans aucune exigence ou dépendance supplémentaire.

Lorsque vous exécutez ant sur n'importe quelle plate-forme, cela fonctionne simplement(tm). Vous ne pouvez pas obtenir cela avec make. C'est incroyablement dépendant de la plate-forme et de la configuration.

Une grande raison est que Ant et Maven (et la plupart des outils SCM, CI etE ciblés par java) sont écrits en java par/pour les développeurs java. Cela simplifie l'intégration dans votre environnement de développement et permet à d'autres outils tels que les serveurs CI et CI d'intégrer des parties des bibliothèques ant/maven dans l'infrastructure de génération/déploiement.

Il était une fois que je travaillais sur un projet Java qui utilisait gmake. Mon souvenir est flou mais IIRC nous avons eu du mal à gérer la structure de répertoire de paquets attendue par javac. Je me souviens aussi que la construction de fichiers JAR était un problème à moins que vous n'ayez quelque chose de trivial.

Ant et Maven abordent le graphique de dépendance de construction et sa gestion à partir d'une vue plus "moderne"... Mais comme le dit Oscar, ils ont créé leurs propres problèmes tout en essayant de résoudre les anciens problèmes avec make.

Je n'ai jamais utilisé GNU Make pour les projets Java, mais j'utilisais jmk. Malheureusement, il n'a pas été mis à jour depuis 2002.

Il avait des fonctionnalités spécifiques à Java mais était suffisamment petit pour être inclus dans votre archive source sans augmenter considérablement sa taille.

De nos jours, je suppose que tout développeur Java avec lequel je partage du code a installé Ant.

ApacheAnt n'est pas quelque chose comme Make. Make consiste à décrire les dépendances entre les fichiers et à créer des fichiers. Ant concerne les dépendances entre les" tâches", et est vraiment plus un moyen de coller des scripts de construction ensemble.

Il peut vous aider AntVsMake