Javaでmakeを使用しないのはなぜですか？

私が見たほとんどすべての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他のインクルードファイルのテキストを取得するために使用され、単一のオブジェクトファイルが出力として書き込まれます。コンパイラは一度に1つずつのシステムであり、オブジェクトファイルを実行可能なバイナリにバインドするための個別のリンク手順があります。

ただし、Javaでは、コンパイラーは実際にでインポートする他のクラスをコンパイルする必要がありますimport。Javaソースコードから必要なすべての依存関係を生成するものを記述makeして、一度に1つずつ正しい順序でクラスを構築することは可能ですが、これでも循環依存関係などのケースは処理されません。

Javaコンパイラーは、他のクラスのコンパイル結果をキャッシュすると同時に、すでにコンパイルされた結果に依存するクラスをさらにコンパイルすることで、より効率的にすることもできます。この種の自動依存関係評価は、make単独では実際には不可能です。

この質問は、誤った仮定に基づいていますmake。重要な数の開発者が使用しています。Java Build Tools：Ant vs. Mavenを参照してください。開発者が使用しない理由については、make多くの開発者が使用したことがないか、使用せずにmake 1000太陽よりも熱い炎でそれを嫌っていました。そのため、彼らは代替ツールを使用しています。

実際には、makeはすべての古いJavaファイルの1つのコマンドで再コンパイルを処理できます。ディレクトリ内のすべてのファイルをコンパイルしたくない場合、または特定の順序が必要な場合は、最初の行を変更してください...

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、より良いメイクよりもJavaのに適した、またはハンクゲイが指摘するように、彼らはないかもしれすることができる:)

ただし、AntとMavenがJavaで記述されていることが重要かどうかを尋ねました。StackOverflowでは、そのような考え（クローズド！プログラミング関連ではない！など）は考慮していませんが、コースはその一部です。RailsではRakeを使用し、Cの男はmakeを使用し、JavaではAntとMavenを使用します。AntまたはMavenの開発者がJava開発者をおそらく他の人よりもよく見守るのは事実ですが、別の質問もあります。Antタスクを何で作成しますか？Java。あなたがJava開発者であれば、それは簡単に適合します。

そうです、その一部は、あなたが使用している言語で書かれたツールを使用することです。

Ant以降のMavenは、Make（プロセス中に新しい問題を作成する際に）引き起こされるいくつかの頭痛を解決するように設計されています。

...その後すぐに、いくつかのオープンソースのJavaプロジェクトは、AntがMakefileで抱えていた問題を解決できることに気付きました。

http://ant.apache.org/faq.html#historyから

彼らが何かを解決するのか、単に学ぶために追加のフォーマットを作成するのかは主観的なトピックです。真実は、それはほとんどすべての新しい発明の歴史です。作成者はそれが多くの問題を解決し、元のユーザーはそれらが美徳であると言います。

それが持っている主な利点は、Javaと統合する可能性です。

rakeたとえば、似たような歴史があったと思います。

makeを介してMaven（およびIvy対応のAntセットアップ）によって解決される主要な問題の1つは、依存関係の自動解決と依存関係jarのダウンロードです。

最もありそうな説明は、いくつかの要因が、重要な期間（1990年代後半）にJavaコミュニティ内でmakeを使用することを妨げたと考えています。

1. Javaには複数のプラットフォームが含まれるため、Javaプログラマーは一般に、Unix環境に限定されたプログラマー（CやPerlプログラマーなど）ほどにはUnixツールに熟達していませんでした。これは一般的なものであることに注意してください。間違いなく、Unixを深く理解している才能のあるJavaプログラマーがいます。
2. その結果、彼らはmakeにあまり熟達しておらず、makeを効果的に使用する方法を知りませんでした。
3. Javaを効率的にコンパイルする短くてシンプルなMakefileを作成することは可能ですが、プラットフォームに依存しない方法でそれを行うには、さらに注意が必要です。
4. その結果、本質的にプラットフォームに依存しないビルドツールへの欲求がありました。
5. この環境でAntとその後のMavenが作成されました。

つまり、makeは確実にJavaプロジェクトで使用できますが、事実上のJavaビルドツールにする機会がありました。その瞬間が過ぎました。

スクリプトは本質的にプラットフォームに依存する傾向があります。Javaはプラットフォームに依存しないことになっています。したがって、マルチプラットフォームのソースベースに対して1つのプラットフォームでのみ機能するビルドシステムを用意することは、一種の問題です。

短い答え：なぜなら make良くないから。Cのフロントでも、多くの選択肢がポップアップ表示されます。

長い答え：makeCのコンパイルにはほとんど適さず、Javaのコンパイルにはまったく適さない欠点がいくつかあります。必要に応じて強制的にJavaをコンパイルすることもできますが、問題が発生する可能性があるため、適切な解決策や回避策がないものもあります。ここにいくつかあります：

依存関係の解決

make本質的に、ファイルは互いにツリーのような依存関係を持っていると想定しています。1つのファイルは、他のファイルをいくつかビルドした結果の出力です。ヘッダーファイルを処理するとき、これはすでにCで逆効果です。ヘッダーファイルに対するCファイルの依存関係を表すために-固有のインクルードファイルを生成するmake必要があるmakeため、後者を変更すると、以前のファイルが再構築されます。ただし、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スクリプトです。makeWindowsへのポートがありますが、それが正しく動作するbashためには、ファイルシステムのPOSIXエミュレーションレイヤーを含むのポートにバンドルする必要があります。

これには2つの種類があります。

1. MSYS これはPOSIX変換をファイルパスに制限しようとするため、専用に作成されていない外部ツールを実行するときに不快な問題が発生する可能性があります。

2. cygwin完全なPOSIXエミュレーションを提供します。ただし、結果として得られるプログラムは、依然としてそのエミュレーション層に依存する傾向があります。

そのため、Windowsでは、標準のビルドツールはまったく同じmakeではなくMSBuild、XMLベースのツールであり、原則としてに近いツールですant。

対照的に、antはJavaで構築されており、あらゆる場所で実行でき、プラットフォームに依存しない方法でファイルを操作してコマンドを実行するための「タスク」と呼ばれる内部ツールが含まれています。を使用するantよりも、実際にWindowsでCプログラムを作成するほうが簡単なほど、用途は広いですmake。

そして最後のマイナーなもの：

Cプログラムでさえmakeをネイティブに使用しない

最初はこれに気付かないかもしれませんが、Cプログラムには通常、が同梱されていませんMakefile。それらは、実際のを生成するCMakeLists.txt、またはbash構成スクリプトとともに出荷されますMakefile。対照的に、使用して構築されたJavaプログラムのソースは、事前に作成antされたantスクリプトとともに出荷されます。A Makefileは他のツールの製品です-それだけでmakeは、それだけでビルドツールになるのに不適切です。antスタンドアロンであり、追加の要件や依存関係なしに、Javaビルドプロセスに必要なすべてを扱います。

ant任意のプラットフォームで実行すると、Just Works（tm）になります。あなたはそれを得ることができませんmake。信じられないほどプラットフォームと構成に依存しています。

私が誰でもない限り、誰もがJavaのmakeを（誤用）していないという仮定は間違っています。

「GNU Makeを使用したプロジェクトの管理」（GFDLで利用可能）には、makeJavaプロジェクトでの使用に特化した完全な章が含まれています。

他のツールの代わりにmakeを使用することの長所と短所の長い（うまくいけば公平な）リストが含まれているので、そこで調べてみるとよいでしょう。（参照：http : //oreilly.com/catalog/make3/book/）

AntはMakefileに対するXML構成指向の改善であり、MavenはAntに対する依存関係ビルドツールの改善です。一部のプロジェクトは3つすべてを使用します。JDKプロジェクトでは、makefileとantを組み合わせて使用​​していたと思います。

大きな理由の1つは、AntとMaven（およびほとんどのJavaターゲットSCM、CI、IDEツール）がJava開発者向けにJavaで記述されていることです。これにより、開発環境への統合が簡単になり、IDEサーバーやCIサーバーなどの他のツールで、ビルド/デプロイメントインフラストラクチャ内のant / mavenライブラリーの一部を統合できるようになります。

むかしむかし、gmakeを使用するJavaプロジェクトに取り組みました。私の思い出はかすんでいますが、IIRCはjavacが期待するパッケージディレクトリ構造を扱うのに苦労しました。また、些細なことがなければ、JARファイルの作成が面倒だったことも覚えています。

ApacheAntはMakeのようなものではありません。Makeは、ファイル間の依存関係、およびファイルの構築方法を記述することです。Antは、「タスク」間の依存関係に関するものであり、ビルドスクリプトを互いに結び付ける方法の1つです。

AntVsMakeを助けるかもしれません

AntとMavenはビルド依存関係グラフとその管理をより「現代的な」視点からアプローチします...しかし、オスカーが言うように、彼らはmakeで古い問題に対処しようとしながら、独自の問題を作成しました。

JavaプロジェクトにGNU Makeを使用したことはありませんが、以前はjmkを使用していました。残念ながら、2002年以降更新されていません。

Java固有の機能がいくつかありましたが、サイズを大幅に増やすことなくソースtarballに含めるのに十分な大きさでした。

最近では、コードを共有するJava開発者にAntがインストールされていると思います。