すべてまたはほとんどすべて(そして運が悪ければ)、ソースコードからプログラムをコンパイルする必要がありました。 実際、ほとんどのプロジェクトでは、。/ configure && make && make installを実行してプログラムをインストールするだけで十分ですが、さまざまな代替方法を確認します。
GNUメイク
GNU Makeは低レベルのコンパイルシステムであり、いくつかの設定が行われ、テストは実行されません。
長所:
- 非常に普及している
- わかりやすい
- 速い
短所:
- 構成がほとんどできない
- 維持するのが難しい
- テストを実行しません
make
BSD メイク
BSD Makeは、現在BSDオペレーティングシステムで使用されているMakeの別のバージョンです。 あまり普及していませんが、機能的に最も包括的なBSDMakeであるGNUMakeが異なります。
長所:
- 速い
- わかりやすい
- GNUMakeよりも多くの機能
短所:
- Linuxの世界では広まっていない
- テストを実行しません
- 構成がほとんどできない
- 維持するのが難しい
make
オートツール
Autotoolsは公式のGNUシステムであり、対応するGNU MakeMakefileを生成するために呼び出す必要があるconfigureというスクリプトを生成します。 それは広く拡張されていますが、ますます多くの人々(私自身を含む)は、それがあまりにも面倒で、難しく、遅く、あまり互換性がないと考えています。
長所:
- 高度に構成可能
- 非常に普及している
短所:
- UNIX以外のシステム間の移植性はほとんどありません
- 実行するテストが多すぎます(すべてをチェックし、すべてがすべてです)
- 構成時に非常に遅い
- 下位互換性が低い
./configure && make
CMake
(私のお気に入りのシステム)CMakeは、そのひどい下位互換性や移植性など、多くの面でAutotoolsの欠点を補うようになるシステムです。 また、各プロジェクトのニーズに合わせて高度に構成可能なテストシステムを改善します。 真実は、ますます多くのプロジェクトがKDE、PortAudio、Ogre3DなどのCMakeを使用しているということです。 このタイプのシステムは、EclipseまたはCodeBlocks用のMakefileまたはプロジェクトを生成するCMakeLists.txtファイルのおかげで認識できます。
長所:
- 速い
- 優れたクロスプラットフォームサポート
- 非常にカスタマイズ可能な方法でテストを定義できます
短所:
- 最初は理解しにくい
- 最初は怖いことがある抽象化で作業する必要があります
- 少しずつ成長しますが少し広がります
cmake . && make
Qメイク
QMakeは、Qtで作成されたプロジェクトをコンパイルするためにTrolltechによって設計されたシステムです。 このように、qmakeはQtに多くの重点を置き、通常はQtCreatorなどのIDEで使用される形式です。 Qtプロジェクトでは非常に人気がありますが、この環境以外では見つかりません。
長所:
- Qtと非常によく統合されています
- 速い
- Qt内の優れたマルチプラットフォーム
短所:
- Qtアプリ以外では珍しい
qmake . && make
SCコン
SConsは、C / C ++プロジェクトをコンパイルするためのPythonベースのシステムです。 Autotoolsとは異なり、CMakeまたはQMake。 SConsはMakefileを作成しません。 SConsは非常に変更可能ですが、単純な操作ではおそらく最も遅いです
長所:
- 簡単な変更
- 公正なテストを受ける
短所:
- 少し広がった
- 遅い
scons
ブースト・ジャム
Boost.Jamは、人気のあるC ++ Boostライブラリで使用されているPerforceJamのバージョンですが、コンパイルシステムは個別に使用できます。 GNU Makeとは異なり、Boost.JamはMakefileの改良版であるJamfileを使用します。 BeOS / Zeta / Haiku環境で非常に人気があります。
長所:
- 速い
- 書くのに最短
短所:
- 少し広がった
- テストの実行の難しさ
bjam
忍者
Ninjaは、元々Chromiumプロジェクト用に設計された超高速ビルドシステムを提供するためにGoogleが開発したシステムです。 忍者は簡単に変更できるようには設計されていません。自身の作者によると、忍者を生成するシステムを見つける必要があります。 推奨されるのはCMakeとgypです。
長所:
- ムイ・ラピド
短所:
- 忍者をスポーンするには別のシステムが必要です
- 少し広がった
ninja
その他
独自のbashやpythonスクリプトなどの他のシステムを使用できます。 Gradle、Maven、gypなどのように使用できる他の非母国語用のジェネレーターもあります。
Makeはコンパイルシステムではなく、ソースコードからのバイナリ(またはターゲット)のジェネレータです。 タスクランナーとしても使用できます。
私はあなたとは異なり、BSD makeは機能が広く、GNU makeはより完全で、より多くの機能を備えています。 そして、私自身の経験からこれを言います。BSDmakeはGNU makeに比べて非常に単純なので、BSDでは常にGNUmakeをインストールする必要があります。
Autotoolsは非常に面倒であることに同意します。私は、Makefileを使用することを好みます。 Autotoolsによって生成されたMakefileはデバッグが困難です。
ご挨拶!
コメントありがとうございます!
私の意見では、GNU makeは常に元のmakeプログラムに対してより伝統的で忠実であり、BSD makeは常により革新的でしたが、比較を行うときに他のことに気付いたのかもしれません。
Autotoolsは本当に大きな頭痛の種です。 Haikuオペレーティングシステムへの貢献者として、私はautotoolsでソフトウェアを移植しなければなりませんでした、そしてそれは地獄です。 この混乱を修正する前に、MakefileまたはCMakeLists.txtを作成することになったケースは少なくありません。
私は現在、Luaスクリプトに基づいて非常に構成可能でシンプルなPremake4を使用しています。 わからない場合はご覧ください。
記事おめでとう、シンプルで簡潔な、優れたリファレンス。
'make check'は、makeを使用した後にコンパイルをチェックするために使用されます
ご挨拶