definicion - ¿Por qué nadie usa make para Java?

setlayout jpanel (17)

Érase una vez que trabajé en un proyecto de Java que usaba gmake. Mi recuerdo es confuso, pero el IIRC nos costó mucho lidiar con la estructura del directorio del paquete que javac espera. También recuerdo que crear archivos JAR era una molestia a menos que tuvieras algo trivial.

Casi todos los proyectos de Java que he visto usan Maven o Ant. Son buenas herramientas y creo que cualquier proyecto puede usarlas. Pero, ¿qué pasó para make ? Se usa para una variedad de proyectos que no son de Java y puede manejar fácilmente Java. Seguro que tienes que descargar make.exe si usas Windows, pero Ant y Maven tampoco vienen con el JDK.

¿Hay alguna falla fundamental con make cuando se usa con Java? ¿Es solo porque Ant y Maven están escritos en Java?

A menos que no sea nadie, la suposición de que nadie está (mal) usando make para Java está mal.

"Gestionar proyectos con GNU Make" (disponible bajo GFDL) contiene un capítulo completo dedicado a usar make con proyectos java.

Como contiene una lista larga (y afortunadamente justa) de los pros y los contras del uso de make en lugar de otras herramientas, es posible que desee echar un vistazo allí. (ver: http://oreilly.com/catalog/make3/book/ )

Ant es una mejora orientada a la configuración XML sobre Makefiles y Maven es una mejora de la herramienta de construcción de dependencia sobre Ant. Algunos proyectos usan los tres. Creo que los proyectos JDK solían usar una mezcla de makefiles y hormiga.

Ant y Maven abordan el gráfico de dependencia de compilación y su gestión desde una perspectiva más "moderna" ... Pero, como dice Oscar, crearon sus propios problemas al intentar abordar los viejos problemas con make.

Ant y más tarde Maven fueron diseñados para resolver algunos dolores de cabeza causados por Make (mientras crean otros nuevos en el proceso). Es solo evolución.

... Poco después, varios proyectos Java de código abierto se dieron cuenta de que Ant podía resolver los problemas que tenían con Makefiles ....

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

Si resuelven algo o simplemente crean un formato adicional para aprender es un tema subjetivo. La verdad es que es más o menos la historia de cada nueva invención: el creador dice que resuelve muchos problemas y los usuarios originales dicen que son virtudes.

La principal ventaja que tiene, es la posibilidad de integrarse con java.

Supongo que una historia similar sería con rake por ejemplo.

ApacheAnt no se parece en nada a Make. Hacer trata sobre la descripción de las dependencias entre archivos y cómo crear archivos. Ant se trata de dependencias entre "tareas", y es realmente una manera más de pegar secuencias de comandos de construcción.

puede ayudar a AntVsMake

Creo que la explicación más probable es que varios factores desalientan el uso de make dentro de la comunidad Java en un período crítico de tiempo (fines de la década de 1990):

Dado que Java abarca múltiples plataformas, los programadores de Java en general no eran tan expertos en las herramientas de Unix como lo eran los programadores generalmente confinados a un entorno Unix (por ejemplo, los programadores C y Perl). Tenga en cuenta que esto es EN GENERAL. Sin duda, hay y fueron programadores de Java dotado con un profundo conocimiento de Unix.
En consecuencia, eran menos hábiles para hacer y no sabían cómo usar de manera efectiva.
Si bien es posible escribir un Makefile corto y simple que compila Java de manera eficiente, se requiere un cuidado especial para hacerlo de una manera independiente de la plataforma.
En consecuencia, había un apetito por una herramienta de compilación intrínsecamente independiente de la plataforma.
Fue en este entorno que se crearon Ant y más tarde Maven.

En resumen, si bien es cierto que se puede usar para proyectos de Java, hubo un momento de oportunidad para convertirlo en la herramienta de construcción Java de facto. Ese momento ha pasado.

El problema fundamental con Make y Java es que Make funciona con la premisa de que tiene que especificar una dependencia y luego una regla para resolver esa dependencia.

Con C básico, típicamente "para convertir un archivo main.c en un archivo main.o, ejecute" cc main.c ".

Puedes hacerlo en Java, pero aprendes rápidamente algo.

En su mayoría, el compilador javac tarda en iniciarse.

La diferencia entre:

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

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

es noche y día.

Agudiza eso con cientos de clases, y simplemente se vuelve insostenible.

Luego combina eso con el hecho de que java tiende a organizarse como grupos de archivos en directorios, vs C y otros que tienden hacia una estructura más plana. Make no tiene mucho soporte directo para trabajar con jerarquías de archivos.

Hacer tampoco es muy bueno para determinar qué archivos están desactualizados, a nivel de colección.

Con Ant, pasará y resumirá todos los archivos que están desactualizados, y luego los compilará de una vez. Make simplemente llamará al compilador de Java en cada archivo individual. Tener NO hacer esto requiere de herramientas externas suficientes para demostrar realmente que Make no está a la altura de la tarea.

Es por eso que surgieron alternativas como Ant y Maven.

El programa venerable make maneja lenguajes compilados por separado, como C y C ++ razonablemente bien. Compila un módulo, utiliza #include para obtener el texto de otros archivos incluidos y escribe un solo archivo de objeto como salida. El compilador es en gran medida un sistema de uno por uno, con un paso de enlace separado para vincular los archivos de objeto en un binario ejecutable.

Sin embargo, en Java, el compilador tiene que compilar realmente otras clases que importe con la import . Aunque sería posible escribir algo que generara todas las dependencias necesarias del código fuente de Java, de modo que make creara las clases en el orden correcto, una a la vez, esto aún no manejaría casos como las dependencias circulares.

El compilador de Java también puede ser más eficiente almacenando en caché los resultados compilados de otras clases mientras compila más clases que dependen de los resultados de las compiladas. Este tipo de evaluación de dependencia automática no es realmente posible con make alone.

En realidad, make puede manejar la recompilación en un comando de todos los archivos java obsoletos. Cambie la primera línea si no desea compilar todos los archivos en el directorio o desea un orden específico ...

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

La pregunta se basa en una suposición incorrecta: un número no trivial de desarrolladores usa make . Vea las herramientas de compilación de Java: Ant vs. Maven . En cuanto a por qué un desarrollador no usaría make : muchos desarrolladores nunca usaron make , o lo usaron y lo odiaron con un fuego que quema más de mil soles. Como tal, usan herramientas alternativas.

Los scripts tienden a ser inherentemente dependientes de la plataforma. Se supone que Java es independiente de la plataforma. Por lo tanto, tener un sistema de compilación que solo funcione en una plataforma para una base de origen multiplataforma es un problema.

Nunca utilicé proyectos de GNU Make para Java, pero solía usar jmk . Lamentablemente no se ha actualizado desde 2002.

Tenía alguna funcionalidad específica de Java, pero era lo suficientemente pequeña como para incluirla en su tarball fuente sin aumentar significativamente su tamaño.

Hoy en día solo asumo que cualquier desarrollador de Java con el que comparto el código tiene Ant instalado.

Respuesta corta: Porque make no es bueno. Incluso en el frente C ves muchas alternativas apareciendo.

Respuesta larga: make tiene varios defectos que lo hacen apenas adecuado para compilar C, y no es adecuado para compilar Java. Puede obligarlo a compilar Java, si lo desea, pero espera tener problemas, algunos de los cuales no tienen una solución adecuada o una solución alternativa. Aquí hay algunos:

Resolución de dependencia

make inherentemente espera que los archivos tengan una dependencia de árbol entre sí, en la cual un archivo es el resultado de construir varios otros. Esto ya es contraproducente en C cuando se trata de archivos de encabezado. make requiere que se genere un archivo de inclusión específico de make para representar la dependencia de un archivo C en sus archivos de encabezado, por lo que un cambio en este último provocaría la reconstrucción previa. Sin embargo, dado que el archivo C en sí mismo no se recrea (simplemente se reconstruye), a menudo se requiere especificar el destino como .PHONY . Afortunadamente, GCC admite generar esos archivos automáticamente.

En Java, la dependencia puede ser circular, y no hay ninguna herramienta para autogenerar dependencias de clases en el formato make . La tarea Depend puede, en cambio, leer el archivo de clase directamente, determinar qué clases importa y eliminar el archivo de clase si alguno de ellos está desactualizado. Sin esto, cualquier dependencia no trivial puede hacer que te veas forzado a usar compilaciones limpias repetidas, eliminando cualquier ventaja de usar una herramienta de compilación.

Espacios en nombres de archivo

Si bien ni Java ni C alientan el uso de espacios en los nombres de los archivos de código fuente, esto puede ser un problema incluso si los espacios están en la ruta del archivo. Considere, por ejemplo, si su código fuente existe en C:/My Documents/My Code/program/src . Esto sería suficiente para romper la make . Esto se debe a que make trata los nombres de archivo como cadenas. ant trata las trayectorias como objetos especiales.

Escaneo de archivos para compilación

make requiere establecer explícitamente qué archivos se deben construir para cada destino. ant permite especificar una carpeta que se escaneará automáticamente para los archivos de origen. Puede parecer una conveniencia menor, pero considere que en Java cada nueva clase requiere un nuevo archivo. Agregar archivos al proyecto puede convertirse en una gran molestia rápidamente.

Y el mayor problema con make :

make depende de POSIX

El lema de Java es "compilar una vez que se ejecute en todas partes". Pero restringir esa compilación a los sistemas basados en POSIX, en los que el soporte de Java es realmente el peor, no es la intención.

Las reglas de compilación en make son esencialmente pequeños scripts bash . A pesar de que hay un puerto de make en Windows, para que funcione correctamente, tiene que estar incluido con un puerto de bash , que incluye una capa de emulación POSIX para el sistema de archivos.

Esto viene en dos variedades:

MSYS que trata de limitar la traducción de POSIX a las rutas de archivos, y por lo tanto puede tener inconvenientes desagradables cuando se ejecutan herramientas externas no hechas especialmente para ello.
cygwin que proporciona una emulación POSIX completa. Los programas resultantes, sin embargo, tienden a depender todavía de esa capa de emulación.

Por esa razón, en Windows, la herramienta de compilación estándar ni siquiera está MSBuild , sino más bien MSBuild , que también es una herramienta basada en XML, más cercana en principio a la ant .

Por el contrario, ant está construida en Java, puede ejecutarse en todas partes y contiene herramientas internas, llamadas "tareas", para manipular archivos y ejecutar comandos de una manera independiente de la plataforma. Es lo suficientemente versátil como para que le resulte más fácil construir un programa C en Windows utilizando una ant que utilizando make .

Y una última menor:

Incluso los programas C no usan make natively

Puede que inicialmente no lo note, pero los programas C generalmente no se envían con un Makefile . Se envían con un CMakeLists.txt , o un script de configuración bash , que genera el Makefile real. Por el contrario, la fuente de un programa Java creado utilizando ant se envía con una secuencia de comandos ant pre-built. Un Makefile es un producto de otras herramientas: esa es la cantidad de make que no es adecuada para ser una herramienta de compilación en sí misma. ant es independiente y trata con todo lo que necesita para su proceso de compilación de Java, sin ningún requisito o dependencia adicional.

Cuando ejecutas ant en cualquier plataforma, solo funciona (tm). No puedes obtener eso con make . Es increíblemente dependiente de la plataforma y la configuración.

Todas las otras respuestas sobre los méritos técnicos de cada una son verdaderas. Ant y Maven pueden ser más adecuados para Java que para make, o como Hank Gay señala, es posible que no :)

Sin embargo, preguntaste si es importante que Ant y Maven estén escritos en Java. Aunque en no consideramos tales pensamientos (¡cerrados, no relacionados con la programación, etc.), POR SUPUESTO, ESTO ES PARTE DEL ASUNTO. En los rieles utilizamos Rake, C dudes usa make, y en Java usamos Ant y Maven. Si bien es cierto que los desarrolladores de Ant o Maven cuidarán al desarrollador de Java quizás mejor que otros, también hay otra pregunta: ¿en qué escribes las tareas Ant? Java. Si eres un desarrollador de Java, es una opción fácil.

Así que sí, una parte es usar herramientas escritas en el idioma que estás utilizando.

Una gran razón es que tanto Ant como Maven (y la mayoría de las herramientas dirigidas a Java SCM, CI e IDE) están escritas en Java por / para desarrolladores de Java. Esto facilita la integración en su entorno de desarrollo y permite que otras herramientas, como los servidores IDE y CI, integren partes de las bibliotecas ant / maven dentro de la infraestructura de compilación / despliegue.

Uno de los principales problemas resueltos por Maven (e Ivy-enabled Ant setups) sobre make es la resolución de dependencia automatizada y la descarga de sus jar de dependencia.