実際には、Autotoolsの唯一の真の「恵みを節約する」とは、それがすべてのGNUプロジェクトが主に使用していることです。
Autotoolsの問題：
- 真のARCANE m4マクロ構文と「互換性」などのテストのための詳細なツイストシェルスクリプトの組み合わせ
- 注意を払っていない場合は、クロスコンパイル機能が台無しになります（NokiaがScratchbox / Scratchbox2を使用して、Maemo / Meegoの非常に壊れたAutotoolsビルド設定を回避するようにしたことは明らかです）。理由は、テストに固定された静的パスが含まれている場合、sysrootの仕様を尊重せず、ホストシステムからデータを取得するため、クロスコンパイルのサポートを無効にすることになります。クロスコンパイルのサポートを解除すると、OpenEmbeddedなどでコードが使用できなくなり、ターゲットではなくクロスコンパイラでリリースをビルドしようとするディストリビューションにとってコードが「楽しく」なります。
- NOBODYが現在この時代のほとんどすべての製品で使用している古くて壊れたコンパイラの問題について、膨大な量のテストを実行します。Solaris、AIXなどの非常に古いバージョンでglibc、libstdc ++、GCCなどを構築していない限り、テストは時間の浪費であり、上記のような多くの多くの潜在的な破損の原因となります。
- AutotoolsをセットアップしてWindowsシステムで使用可能なコードを作成するのは、かなり辛い経験です。（私はWindowsをほとんど使用していませんが、クロスプラットフォームのコードを開発しているとしたら深刻な問題です。）
- それが壊れると、スクリプトを書いた人がビルドを整理するのに間違えたものを整理するために、HOURSが尻尾を追いかけて過ごすことになります（実際、これは私がやろうとしていることです（または、むしろ、 Autotoolsを完全にリッピングします。今月の残りの期間には、混乱を解消するのに十分な時間がないと思います...）これを入力しているので、今すぐ作業できます。ApacheThriftには、交差しない壊れたビルドシステムの1つがあります。-コンパイル。）
- 「通常の」ユーザーは実際には単に「./configure; make」を実行することはできません。多くのことについて、PPAや配布ベンダーなど、誰かから提供されたパッケージをプルすることになります。「通常の」ユーザーは開発者ではなく、多くの場合tarballを取得していません。それがそこに当てはまるだろうと推定するための皆の側のそれは控えめです。tarballの一般的なユーザーは、物事をやっている開発者であるため、破損がある場合、その破損を非難することになります。
それは機能します...ほとんどの場合... Autotoolsについて言えることはそれだけです。これは、GNUプロジェクトにのみ関係するいくつかの問題を解決するシステムです...そのベースとなるコアツールチェーンコードについてです。（編集（2014年5月24日））：この種の懸念は心配する必要がある潜在的に悪いことであることに注意してください-Heartbleedはこの考え方から部分的に生じており、正しい最新のシステムでは、本当にAutotoolsが修正することの多くを扱うビジネスはありません。GNUはおそらく、Heartbleedで何が起こったかに照らして、コードベースを手際よく削除する必要があります）これを使用してプロジェクトを実行でき、Linux以外の場所では機能しないと思われる小さなプロジェクトでうまく機能する可能性がありますGNUツールチェーンは明らかに正しく機能しています。声明は「きれいのLinuxと統合」であることは非常に大胆な声明とはかなり間違いました。それは、GNU toolsuiteと合理的にうまく統合し、ITがその目標に持っている問題を解決します。
これは、ここのスレッドで説明されている他のオプションに問題がないと言っているのではありません。
SConsはMake / GMake / etcの代替品です。見た目はとてもいいですが、すべてを考慮しましたが...
- それでも、実際にはPOSIXのみのツールです。AutoToolsを使用するよりも、MinGWでこれを使用してWindowsを構築する方が簡単かもしれませんが、それでもPOSIXを実行するように調整されており、使用するにはPython と SConsをインストールする必要があります。
- Scratchbox2のようなものを使用していない限り、クロスコンパイルの実行に問題があります。
- 独自の比較から、CMakeよりも明らかに遅く、安定性が低いです。SConsと比較して、CMakeのネガティブな部分（POSIX側ではmake / gmakeをビルドする必要があります...）が出てきます。（余談として、あなたが必要としている場合ことを他のソリューションに比べて大幅に拡張性は、あなたのプロジェクトがあまりにも複雑だかどうかを自分自身に尋ねるべきです...）
このスレッドでのCMakeの例は少し偽物です。
しかしながら...
- 新しい言語を学ぶ必要があります。
- Make、SCons、Autotoolsに慣れていると、直感に反することが起こります。
- ビルドするシステムにCMakeをインストールする必要があります。
- ビルド済みのバイナリがない場合は、堅牢なC ++コンパイラが必要です。
実際、あなたの目標は、ここで何を選択するかを決定する必要があります。
- あなたが対処する必要がありますかLOTな作業バイナリを生成するために壊れたツールチェーンの？はいの場合は、上記で述べた欠点を認識しながら、Autotoolsを検討することをお勧めします。CMakeはこれの多くに対処できますが、Autotoolsほど心配する必要はありません。SConsはそれを心配するように拡張できますが、すぐに使える答えではありません。
- Windowsターゲットについて心配する必要がありますか？もしそうなら、Autotoolsは文字通り実行されていないはずです。もしそうなら、SConsは良い選択かもしれませんし、そうでないかもしれません。もしそうなら、CMakeは確かな選択です。
- あなたはクロスコンパイルを心配する必要は（ユニバーサルアプリは/ライブラリは、などGoogleのProtobufs、Apacheのスリフト、のようなものがありますかべきである ...これを気にしますか）？もしそうなら、Autotools はWindowsについて心配する必要がない限り、あなたのために働きますが、物事があなたに変化するとき、あなたはあなたの設定システムを維持するために多くの時間を費やすことになります。SConsは、Scratchbox2を使用している場合を除いて、現時点ではほとんど問題ありません。実際にはクロスコンパイルに対応しておらず、その拡張性を使用して、次のように維持する必要があります。 Automakeを使用します。もしそうなら、サンドボックスからのリークの心配がなくクロスコンパイルをサポートし、Scratchbox2のようなものの有無にかかわらず動作し、OpenEmbeddedのようなものとうまく統合するため、CMakeを検討することをお勧めします。
多くの、多くのプロジェクトがqmakeやAutotoolsなどを捨て、CMakeに移行しているのには理由があります。これまでのところ、プロジェクトがWindowsのみまたはOSXのみの部分を考慮していないため、CMakeベースのプロジェクトがクロスコンパイル状況またはVisualStudioセットアップにドロップするか、少量のクリーンアップが必要になることを期待できます。コードベースに。私は実際にプロジェクト-ベースSConsはの外を期待することはできませんし、私は完全に得ているために1 /第3回以上Autotool群のプロジェクトを期待SOMETHING排除は、それが1つまたはScratchbox2の1を構築するホスト以外の任意の文脈上で右構築することを間違って。