아무도 make for Java를 사용하지 않는 이유는 무엇입니까?

아무도 make for Java를 사용하지 않는 이유는 무엇입니까?

---

내가 본 모든 Java 프로젝트는 Maven 또는 Ant를 사용합니다. 그들은 훌륭한 도구이며 거의 모든 프로젝트에서 사용할 수 있다고 생각합니다. 그러나 이제까지 우연히 만들어 ? Java 이외의 다양한 프로젝트에 사용되며 Java를 쉽게 처리 할 수 ​​있습니다. Windows를 사용하는 경우 make.exe를 다운로드해야하지만 Ant 및 Maven에도 JDK가 제공되지 않습니다.

Java와 함께 사용할 때 make에 근본적인 결함이 있습니까? Ant와 Maven이 Java로 작성 되었기 때문입니까?

---

Make와 Java의 근본적인 문제는 Make가 종속성을 지정한 전제에서 작동 한 다음 해당 종속성을 해결하는 규칙에서 작동한다는 것입니다.

기본 C에서 "main.c 파일을 main.o 파일로 변환하려면"cc main.c "를 실행하십시오.

Java로 할 수는 있지만 빠르게 배울 수 있습니다.

대부분 javac 컴파일러가 느리게 시작됩니다.

차이점은 다음과 같습니다.

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

과

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

밤낮입니다.

수백 개의 클래스로 그것을 악화시키고, 그것은 단지 참을 수 없게됩니다.

그런 다음 Java와 디렉토리의 파일 그룹으로 구성되는 경향이 있다는 사실과 C 및 더 평평한 구조를 선호하는 다른 파일과 결합합니다. Make는 파일 계층 작업을 직접적으로 지원하지 않습니다.

또한 Make는 컬렉션 수준에서 오래된 파일을 결정하는 데 매우 적합하지 않습니다.

Ant를 사용하면 오래된 파일을 모두 요약 한 다음 한 번에 컴파일합니다. Make는 단순히 각 개별 파일에서 Java 컴파일러를 호출합니다. 이렇게하지 않으면 Make가 작업에 크게 영향을 미치지 않는다는 것을 보여줄 수있는 충분한 외부 도구가 필요합니다.

그렇기 때문에 Ant 및 Maven과 같은 대안이 등장했습니다.

---

훌륭한 make프로그램은 C 및 C ++와 같이 별도로 컴파일 된 언어를 합리적으로 잘 처리합니다. 모듈을 컴파일하면 #include다른 포함 파일의 텍스트를 가져오고 단일 객체 파일을 출력으로 씁니다. 컴파일러는 객체 파일을 실행 가능한 이진 파일에 바인딩하기위한 별도의 연결 단계가있는 한 번에 하나의 시스템입니다.

그러나 Java에서는 컴파일러가 실제로 가져 오는 다른 클래스를 컴파일 해야합니다 import. Java 소스 코드에서 필요한 모든 종속성을 생성하여 make한 번에 하나씩 올바른 순서로 클래스를 빌드 하는 것을 작성할 수는 있지만 순환 종속성과 같은 경우는 처리하지 않습니다.

Java 컴파일러는 다른 클래스의 컴파일 된 결과를 캐싱하면서 이미 컴파일 된 클래스의 결과에 의존하는 추가 클래스를 컴파일함으로써보다 효율적일 수 있습니다. 이러한 종류의 자동 종속성 평가는 make단독으로 는 불가능합니다 .

---

이 질문은 잘못된 가정에 근거합니다. 사소한 수의 개발자 가 사용 make합니다. Java 빌드 도구 : Ant 및 Maven을 참조하십시오 . 왜 개발자 가 사용 하지 않는지에 관해서는 make: 많은 개발자들이 make그것을 사용 하지 않았 거나 그것을 사용하여 1000 태양보다 더 뜨거워지는 불로 그것을 미워했습니다. 따라서 대체 도구를 사용합니다.

---

실제로 make는 모든 오래된 Java 파일 중 하나의 명령으로 재 컴파일을 처리 할 수 ​​있습니다. 디렉토리의 모든 파일을 컴파일하지 않거나 특정 순서를 원하면 첫 번째 줄을 변경하십시오 ...

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

---

각각의 기술적 장점에 대한 다른 모든 대답은 사실입니다. Ant그리고 Maven더 나은 메이크업보다 자바에 적합, 또는 행크 게이가 지적 하듯, 그들은하지 않을 수 있습니다 할 수있다 :

However, you asked if it matters that Ant and Maven are written in Java. Although on StackOverflow we don't consider such thoughts (closed! not-programming-related! etc.), OF COURSE THAT'S PART OF THE THING. On rails we use Rake, C dudes use make, and in Java we use Ant and Maven. While it's true that the Ant or Maven developers will look after the Java developer perhaps better than others, there's also another question: what do you write Ant tasks in? Java. If you're a Java developer, that's an easy fit.

So yeah, part of it is to use tools written in the language you are tooling.

---

Ant and later Maven were designed to solve some headaches caused by Make ( while creating new ones in the process ) It is just evolution.

...Soon thereafter, several open source Java projects realized that Ant could solve the problems they had with Makefiles....

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

Whether they solve anything or just create an extra format to learn is a subjective topic. The truth is that's pretty much the history of every new invention: The creator says it solves a lot of problems and the original users say those are virtues.

The main advantage it has, is the possibility to integrate with java.

I guess a similar history would be with rake for instance.

---

One of the major issues solved by Maven (and Ivy-enabled Ant setups) over make is automated dependency resolution and downloading of your dependency jars.

---

I think the most likely explanation is that several factors discouraged the use of make within the Java community in a critical period of time (the late 1990s):

1. Because Java encompasses multiple platforms, Java programmers in general were not as adept at Unix tools as were programmers generally confined to a Unix environment (e.g., C and Perl programmers). Note that this is IN GENERAL. Without a doubt there are and were gifted Java programmers with a deep understanding of Unix.
2. Consequently they were less adept at make and didn't know how to use make effectively.
3. While it is possible to write a short and simple Makefile that compiles Java efficiently, extra care is required to do so in a platform-independent way.
4. Consequently there was an appetite for an intrinsically platform-independent build tool.
5. It was in this environment that Ant and later Maven were created.

In short, while make most certainly can be used for Java projects, there was a moment of opportunity to make it the de facto Java build tool. That moment has passed.

---

Make scripts tend to be inherently platform dependent. Java is supposed to be platform independent. Therefore having a build system that only works on one platform for a multi-platform sourcebase is kindof a problem.

---

Unless I am no one the assumption no one is (mis)using make for java is wrong.

"Managing Projects with GNU Make" (available under GFDL) contains a complete chapter dedicated to using make with java projects.

As it contains a long (and hopefully fair) list of the pros and cons of using make instead of other tools you might want to take a look there. (see: http://oreilly.com/catalog/make3/book/)

---

Short answer: Because make isn't good. Even on the C front you see many alternatives popping up.

Long answer: make has several flaws that make it barely suitable for compiling C, and unsuitable at all for compiling Java. You can force it to compile Java, if you want, but expect running into issues, some of which do not have a suitable solution or workaround. Here are a few:

Dependency resolution

make inherently expects files to have a tree-like dependency on each other, in which one file is the output of building several others. This already backfires in C when dealing with header files. make requires a make-specific include file to be generated to represent the dependency of a C file on its header files, so a change to the latter would cause the prior to be rebuilt. However, since the C file itself isn't recreated (merely rebuilt), make often requires specifying the target as .PHONY. Fortunately, GCC supports generating those files automatically.

In Java, dependency can be circular, and there's no tool for auto-generating class dependencies in make format. ant's Depend task can, instead, read the class file directly, determine which classes it imports, and delete the class file if any of them are out of date. Without this, any non-trivial dependency may result in you being forced to use repeated clean builds, removing any advantage of using a build tool.

Spaces in filenames

While neither Java nor C encourage using spaces in your source code filenames, in make this can be problem even if the spaces are in the file path. Consider, for example, if your source code exists in C:\My Documents\My Code\program\src. This would be enough to break make. This is because make treats filenames as strings. ant treats paths as special objects.

Scanning files for build

make requires explicitly setting which files are to be built for each target. ant allows specifying a folder which is to be auto-scanned for source files. It may seem like a minor convenience, but consider that in Java each new class requires a new file. Adding files to the project can become a big hassle fast.

And the biggest problem with make:

make is POSIX-dependent

Java's motto is "compile once run everywhere". But restricting that compilation to POSIX-based systems, in which Java support is actually the worst, is not the intention.

Build rules in make are essentially small bash scripts. Even though there is a port of make to Windows, for it to work properly, it has to be bundled with a port of bash, which includes a POSIX emulation layer for the file system.

This comes in two varieties:

1. MSYS which tries to limit the POSIX translation to file paths, and can therefore have unpleasant gotchas when running external tools not made especially for it.

2. cygwin which provides a complete POSIX emulation. The resulting programs, however, tend to still rely on that emulation layer.

For that reason, on Windows, the standard build tool isn't even make at all, but rather MSBuild, which is also an XML-based tool, closer in principle to ant.

By contrast, ant is built in Java, can run everywhere, and contains internal tools, called "tasks", for manipulating files and executing commands in a platform-independent way. It's sufficiently versatile that you can actually have an easier time building a C program in Windows using ant than using make.

And one last minor one:

Even C programs don't use make natively

You may not initially notice this, but C programs generally aren't shipped with a Makefile. They are shipped with a CMakeLists.txt, or a bash configuration script, which generates the actual Makefile. By contrast, the source of a Java program built using ant is shipped with an ant script pre-built. A Makefile is a product of other tools - That's how much make is unsuitable to be a build tool on its own. ant is standalone, and deals with everything you need for your Java build process, without any additional requirements or dependencies.

When you run ant on any platform, it Just Works(tm). You can't get that with make. It's incredibly platform and configuration dependent.

---

Ant is an XML configuration oriented improvement over Makefiles and Maven is a dependency build tool improvement over Ant. Some projects use all three. I think the JDK projects used to use a mix of makefiles and ant.

---

One big reason is that both Ant and Maven (and most java targeted SCM, CI and IDE tools) are written in java by/for java developers. This makes it simpler to integrate into your development environment and allows other tools such as the IDE and CI servers to integrate portions of the ant/maven libraries within the build/deployment infrastructure.

---

Once upon a time I worked on a Java project that used gmake. My recollection is hazy but IIRC we had a hard time dealing with the package directory structure that javac expects. I also remember that building JAR files was a hassle unless you had something trivial.

---

ApacheAnt isn't anything like Make. Make is about describing dependencies between files, and how to build files. Ant is about dependencies between "tasks", and is really more of a way of gluing build scripts together.

it may helps you AntVsMake

---

Ant and Maven approach the build dependency graph and the management of it from a more 'modern' view... But as Oscar says, they created their own problems while attempting to address the old problems with make.

---

I've never used GNU Make for Java projects, but I used to use jmk. Sadly it hasn't been updated since 2002.

It had some Java-specific functionality but was small enough to include in your source tarball without significantly increasing its size.

Nowadays I just assume any Java developer I share code with has Ant installed.

참고URL : https://stackoverflow.com/questions/2209827/why-is-no-one-using-make-for-java