왜 아무도 Java용 make를 사용하지 않습니까?

https://stackoverflow.com/questions/2209827

18-09-2019
|

문제

내가 본 거의 모든 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가 이 작업을 수행하지 않도록 하려면 Make가 작업에 적합하지 않다는 것을 실제로 보여주기에 충분한 외부 도구가 필요합니다.

이것이 Ant 및 Maven과 같은 대안이 등장한 이유입니다.

다른 팁

존경하는 make 프로그램은 C 및 C++와 같이 별도로 컴파일된 언어를 합리적으로 잘 처리합니다.모듈을 컴파일하면 다음을 사용합니다. #include 다른 포함 파일의 텍스트를 가져오고 단일 개체 파일을 출력으로 작성합니다.컴파일러는 개체 파일을 실행 가능한 바이너리로 바인딩하기 위한 별도의 연결 단계를 갖춘 한 번에 하나씩 실행되는 시스템입니다.

그러나 Java에서는 컴파일러가 실제로 엮다 함께 가져오는 다른 클래스 import.Java 소스 코드에서 필요한 모든 종속성을 생성하는 것을 작성하는 것이 가능하더라도 make 한 번에 하나씩 올바른 순서로 클래스를 빌드하지만 순환 종속성과 같은 경우는 여전히 처리되지 않습니다.

Java 컴파일러는 이미 컴파일된 클래스의 결과에 의존하는 추가 클래스를 컴파일하는 동시에 다른 클래스의 컴파일된 결과를 캐시함으로써 더 효율적일 수도 있습니다.이런 종류의 자동 종속성 평가는 실제로 불가능합니다. make 홀로.

질문은 잘못된 가정에 기초하고 있습니다.적지 않은 수의 개발자 하다 사용 make.보다 Java 빌드 도구:개미 대메이븐.개발자인 이유에 대해 않을 것이다 사용 make:많은 개발자들이 한 번도 사용해 본 적이 없습니다. make, 또는 그것을 사용하고 천 개의 태양보다 더 뜨겁게 타는 불로 그것을 싫어했습니다.따라서 그들은 대체 도구를 사용합니다.

실제로 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 make보다 Java에 더 적합할 수도 있고 Hank Gay가 지적했듯이 그렇지 않을 수도 있습니다 :)

그러나 Ant와 Maven이 Java로 작성되는 것이 중요한지 물으셨습니다.StackOverflow에서는 그러한 생각을 고려하지 않지만(닫혀 있습니다!프로그래밍과 관련이 없습니다!등), 물론 그것은 문제의 일부입니다.레일에서는 Rake를 사용하고, C에서는 make를 사용하고, Java에서는 Ant와 Maven을 사용합니다.Ant 또는 Maven 개발자가 다른 개발자보다 Java 개발자를 더 잘 돌볼 것이라는 것은 사실이지만 또 다른 질문도 있습니다.Ant 작업을 무엇에 작성하시나요?자바.당신이 자바 개발자라면, 이는 쉬운 일이다.

예, 그 중 일부는 도구를 사용하는 언어로 작성된 도구를 사용하는 것입니다.

Ant와 이후 Maven은 다음으로 인한 몇 가지 문제를 해결하도록 설계되었습니다. Make (그 과정에서 새로운 것을 만들어내면서) 그것은 단지 진화일 뿐입니다.

...곧이어 몇몇 오픈 소스 Java 프로젝트에서는 Ant가 Makefile과 관련된 문제를 해결할 수 있다는 것을 깨달았습니다....

에서 http://ant.apache.org/faq.html#history

문제를 해결하는지 아니면 학습할 추가 형식을 만드는지는 주관적인 주제입니다.진실은 이것이 모든 새로운 발명의 역사와 거의 같다는 것입니다.제작자는 문제가 많이 해결됐다고 하고, 원유저들은 그게 장점이라고 합니다.

가장 큰 장점은 Java와 통합할 수 있다는 것입니다.

비슷한 역사가 있을 것 같아요 rake 예를 들어.

make를 통해 Maven(및 Ivy 지원 Ant 설정)이 해결한 주요 문제 중 하나는 자동화된 종속성 해결 및 종속성 jar 다운로드입니다.

내 생각에 가장 가능성 있는 설명은 중요한 시기(1990년대 후반)에 Java 커뮤니티 내에서 make 사용을 방해하는 몇 가지 요인이 있다는 것입니다.

Java는 여러 플랫폼을 포괄하기 때문에 일반적으로 Java 프로그래머는 일반적으로 Unix 환경에 국한된 프로그래머(예: C 및 Perl 프로그래머)만큼 Unix 도구에 능숙하지 않습니다.이는 일반적인 사항입니다.의심할 바 없이 Unix에 대한 깊은 이해를 갖춘 재능 있는 Java 프로그래머가 있었고 지금도 그렇습니다.
결과적으로 그들은 make에 덜 능숙했고 make를 효과적으로 사용하는 방법을 몰랐습니다.
Java를 효율적으로 컴파일하는 짧고 간단한 Makefile을 작성하는 것이 가능하지만 플랫폼 독립적인 방식으로 이를 수행하려면 특별한 주의가 필요합니다.
결과적으로 본질적으로 플랫폼 독립적인 빌드 도구에 대한 욕구가 생겼습니다.
Ant와 나중에 Maven이 만들어진 것은 바로 이 환경이었습니다.

간단히 말해서 make는 Java 프로젝트에 가장 확실하게 사용될 수 있지만 사실상 Java 빌드 도구로 만들 수 있는 기회가 있었습니다.그 순간이 지났습니다.

Make 스크립트는 본질적으로 플랫폼에 종속되는 경향이 있습니다.Java는 플랫폼 독립적이어야 합니다.따라서 다중 플랫폼 소스 기반에 대해 하나의 플랫폼에서만 작동하는 빌드 시스템을 갖는 것은 일종의 문제입니다.

내가 아무도 아닌 한 누구도 Java에 make를 사용하지 않는다는 가정은 잘못된 것입니다.

"GNU Make로 프로젝트 관리"(GFDL에서 사용 가능)에는 사용에 전념하는 완전한 장이 포함되어 있습니다. make 자바 프로젝트와 함께.

여기에는 다른 도구 대신 make를 사용하는 것의 장단점에 대한 길고(그리고 공평한) 목록이 포함되어 있으므로 여기서 살펴보는 것이 좋습니다.(보다: http://oreilly.com/catalog/make3/book/)

짧은 답변:왜냐하면 make 좋지 않다.C 전면에서도 많은 대안이 나타나는 것을 볼 수 있습니다.

긴 답변: make C 컴파일에는 거의 적합하지 않고 Java 컴파일에는 전혀 적합하지 않게 만드는 몇 가지 결함이 있습니다.원하는 경우 강제로 Java를 컴파일할 수 있지만 문제가 발생할 수 있으며 그 중 일부에는 적절한 솔루션이나 해결 방법이 없습니다.다음은 몇 가지입니다:

종속성 해결

make 본질적으로 파일은 서로 트리와 같은 종속성을 가질 것으로 예상하며, 여기서 하나의 파일은 여러 다른 파일을 빌드한 결과입니다.이는 헤더 파일을 처리할 때 이미 C에서 역효과를 낳습니다. make 필요하다 make- 헤더 파일에 대한 C 파일의 종속성을 나타내기 위해 생성되는 특정 포함 파일입니다. 따라서 후자를 변경하면 이전 파일이 다시 빌드됩니다.그러나 C 파일 자체는 다시 생성되지 않으므로(단순히 다시 빌드됨) make에서는 대상을 다음과 같이 지정해야 하는 경우가 많습니다. .PHONY.다행히 GCC는 이러한 파일을 자동으로 생성하는 기능을 지원합니다.

Java에서는 종속성이 순환적일 수 있으며 클래스 종속성을 자동 생성하는 도구가 없습니다. make 체재. ant'에스 Depend 대신 작업은 클래스 파일을 직접 읽고, 가져올 클래스를 결정하고, 오래된 클래스 파일이 있으면 해당 클래스 파일을 삭제할 수 있습니다.이것이 없으면 사소한 종속성으로 인해 클린 빌드를 반복적으로 사용해야 하여 빌드 도구 사용의 이점이 제거될 수 있습니다.

파일 이름의 공백

Java나 C 모두 소스 코드 파일 이름에 공백을 사용하는 것을 권장하지 않지만 make 파일 경로에 공백이 있어도 문제가 될 수 있습니다.예를 들어, 소스 코드가 C:\My Documents\My Code\program\src.이 정도면 깰만하겠지 make.이 때문입니다 make 파일 이름을 문자열로 처리합니다. ant 경로를 특수 객체로 취급합니다.

빌드를 위한 파일 스캔 중

make 각 대상에 대해 빌드할 파일을 명시적으로 설정해야 합니다. ant 소스 파일을 자동 검색할 폴더를 지정할 수 있습니다.사소한 편리함처럼 보일 수도 있지만 Java에서는 새 클래스마다 새 파일이 필요하다는 점을 고려하세요.프로젝트에 파일을 추가하는 것은 매우 번거로운 일이 될 수 있습니다.

그리고 가장 큰 문제는 make:

make는 POSIX에 종속됩니다.

Java의 모토는 "한 번 실행하면 어디서나 컴파일"입니다.그러나 Java 지원이 실제로 최악인 POSIX 기반 시스템으로 컴파일을 제한하는 것은 의도가 아닙니다.

규칙 작성 make 본질적으로 작다 bash 스크립트.항구가 있음에도 불구하고 make Windows에서 제대로 작동하려면 다음 포트와 함께 번들로 제공되어야 합니다. bash, 파일 시스템용 POSIX 에뮬레이션 계층이 포함되어 있습니다.

이는 두 가지 종류로 제공됩니다.

MSYS POSIX 변환을 파일 경로로 제한하려고 시도하므로 특별히 제작되지 않은 외부 도구를 실행할 때 불쾌한 문제가 발생할 수 있습니다.
cygwin 완전한 POSIX 에뮬레이션을 제공합니다.그러나 결과 프로그램은 여전히 해당 에뮬레이션 계층에 의존하는 경향이 있습니다.

이러한 이유로 Windows에서는 표준 빌드 도구도 지원되지 않습니다. make 전혀, 하지만 오히려 MSBuild, 는 XML 기반 도구이기도 하며 원칙적으로는 다음과 같습니다. ant.

대조적으로, ant Java로 구축되어 어디에서나 실행될 수 있으며 플랫폼 독립적인 방식으로 파일을 조작하고 명령을 실행하기 위한 "작업"이라는 내부 도구가 포함되어 있습니다.실제로 Windows에서 C 프로그램을 작성하는 데 더 쉬운 시간을 가질 수 있을 만큼 충분히 다재다능합니다. ant 사용하는 것보다 make.

그리고 마지막 사소한 것:

C 프로그램조차도 기본적으로 make를 사용하지 않습니다.

처음에는 이것을 눈치 채지 못할 수도 있지만 C 프로그램은 일반적으로 Makefile.그들은 함께 배송됩니다 CMakeLists.txt, 또는 bash 실제를 생성하는 구성 스크립트 Makefile.대조적으로, 다음을 사용하여 구축된 Java 프로그램의 소스는 ant 와 함께 배송됩니다 ant 사전 빌드된 스크립트.ㅏ Makefile 다른 도구의 제품입니다 - 그 정도입니다 make 자체적으로 빌드 도구로 사용하기에는 적합하지 않습니다. ant 독립형이며 추가 요구 사항이나 종속성 없이 Java 빌드 프로세스에 필요한 모든 것을 처리합니다.

당신이 달릴 때 ant 어떤 플랫폼에서든 Just Works(tm)가 작동합니다.당신은 그것을 얻을 수 없습니다 make.엄청나게 플랫폼과 구성에 따라 다릅니다.

Ant는 Makefile에 비해 XML 구성 중심의 개선 사항이고 Maven은 Ant에 비해 개선된 종속성 빌드 도구입니다.일부 프로젝트에서는 세 가지를 모두 사용합니다.JDK 프로젝트에서는 makefile과 ant를 혼합하여 사용했던 것 같습니다.

가장 큰 이유 중 하나는 Ant와 Maven(그리고 대부분의 Java 대상 SCM, CI 및 IDE 도구)이 Java 개발자에 의해/Java 개발자를 위해 Java로 작성되었기 때문입니다.이를 통해 개발 환경에 통합하는 것이 더 간단해지고 IDE 및 CI 서버와 같은 다른 도구가 빌드/배포 인프라 내에서 ant/maven 라이브러리의 일부를 통합할 수 있습니다.

옛날에 저는 gmake를 사용하는 Java 프로젝트에 참여했습니다.내 기억은 흐릿하지만 IIRC에서는 javac가 기대하는 패키지 디렉터리 구조를 처리하는 데 어려움을 겪었습니다.또한 JAR 파일을 만드는 것은 사소한 일이 아닌 이상 번거로웠던 기억이 납니다.

ApacheAnt는 Make와 전혀 다릅니다.Make는 파일 간의 종속성과 파일 빌드 방법을 설명하는 것입니다.Ant는 "작업" 간의 종속성에 관한 것이며 실제로는 빌드 스크립트를 함께 붙이는 방법에 가깝습니다.

그것은 당신에게 도움이 될 수 있습니다 AntVsMake

Ant와 Maven은 보다 '현대적인' 관점에서 빌드 종속성 그래프와 관리에 접근합니다.그러나 오스카가 말했듯이, 그들은 make의 오래된 문제를 해결하려고 시도하면서 그들 자신의 문제를 일으켰습니다.

나는 Java 프로젝트에 GNU Make를 사용한 적이 없지만 jmk.안타깝게도 2002년 이후 업데이트가 되지 않았습니다.

일부 Java 관련 기능이 있었지만 크기를 크게 늘리지 않고도 소스 tarball에 포함할 수 있을 만큼 작았습니다.

요즘에는 코드를 공유하는 Java 개발자가 Ant를 설치했다고 가정합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow