282

Autotools、Cmake、Scons の違いは何ですか?

4

5 に答える 5

214

実際、Autotools の唯一の真の「救い」は、それがすべての GNU プロジェクトで主に使用されていることです。

Autotools に関する問題:

  • 真に ARCANE m4 マクロ構文と、「互換性」などをテストするための冗長でねじれたシェル スクリプトを組み合わせたもの。
  • 注意を怠ると、クロスコンパイル機能が台無しになります (Nokia が Scratchbox/Scratchbox2 を思いついたのは、Maemo/Meego の非常に壊れた Autotools ビルド セットアップを回避するためであることに注意してください)。テストに固定の静的パスがあると、sysroot の仕様を尊重せず、ホスト システムからデータを取得するため、クロス コンパイルのサポートが失われます。クロスコンパイルのサポートを壊すと、コードが OpenEmbedded などで使用できなくなり、ターゲットではなくクロスコンパイラでリリースをビルドしようとするディストリビューションが「楽しく」なります。
  • NOBODYが現在、ほとんどすべての製品で現在使用している、古くて壊れたコンパイラの問題について、膨大な量のテストを行います。本当に古いバージョンの Solaris や AIX などで glibc、libstdc++、GCC などを構築していない限り、テストは時間の無駄であり、上記のような多くの潜在的な破損の原因となります。
  • Windows システムで使用可能なコードをビルドするために Autotools をセットアップするのは、非常につらい経験です。(私は Windows をほとんど使用していませんが、クロスプラットフォーム コードを開発している場合は深刻な懸念事項です。)
  • それが壊れたら、ビルドを整理するためにスクリプトを書いた人が間違っていたものを整理しようとして、何時間もかけて尻尾を追いかけることになります (実際、これは私がやろうとしていることです (または、むしろ、 Autotools を完全に削除する - 今月の残りの時間で混乱を整理するのに十分な時間があるとは思えません...) Apache Thrift には、クロスしない壊れたビルド システムの 1 つがあります。 -コンパイル。）
  • 「通常の」ユーザーは、実際には「./configure; make」を実行するだけではありません。多くの場合、PPA やディストリビューション ベンダーなどから提供されたパッケージをプルします。「通常の」ユーザーは開発者ではなく、多くの場合、tarball を取得していません。それがそこに当てはまると推測するのは、誰にとってもスノッブです。tarball の典型的なユーザーは、何かをしている開発者です。

それは機能します...ほとんどの場合... Autotoolsについて言えることはそれだけです。これは、GNU プロジェクトのみに実際に関係するいくつかの問題を解決するシステムです...そのベース、コア ツールチェーン コードについてです。(編集 (2014 年 5 月 24 日): この種の懸念は、潜在的に悪いことであることに注意してください。Heartbleed は、部分的にこの考え方から生じたものであり、正しい最新のシステムでは、本当にAutotoolsが修正するものの多くを扱うビジネスはありません. GNU は、Heartbleed で起こったことに照らして、おそらくコードベースの粗雑な削除を行う必要があります) プロジェクトを実行するためにそれを使用できます。また、Linux やその他の場所以外では動作しないと予想される小さなプロジェクトでもうまく動作する可能性があります。 GNU ツールチェーンは明らかに正しく動作しています。「Linux とうまく統合する」という記述は、非常に大胆な記述であり、まったく正しくありません。それは GNU ツールスイートと合理的にうまく統合し、IT がその目標に関して抱えている問題を解決します。

これは、ここのスレッドで議論されている他のオプションに問題がないということではありません。

SCons は、Make/GMake/etc の代わりになります。かなり素敵に見えますが、すべてが考慮されていますが...

  • それはまだPOSIX専用のツールです。Autotools を使用するよりも、これを使用して MinGW で Windows のものをビルドする方がおそらく簡単ですが、それでも POSIX のものを実行するのにより適しているため、PythonとSCons をインストールして使用する必要があります。
  • Scratchbox2 などを使用していない限り、クロスコンパイルに問題があります。
  • 確かに、独自の比較から、CMake よりも遅く、安定性が低くなります。彼らは中途半端な (POSIX 側ではビルドに make/gmake が必要です...) SCons と比較して CMake のネガを考え出します。(余談ですが、他のソリューションよりも拡張性が必要な場合は、プロジェクトが複雑すぎるかどうかを自問する必要があります... )

このスレッドで CMake に与えられた例は、少し偽物です。

でも...

  • 新しい言語を学ぶ必要があります。
  • Make、SCons、または Autotools に慣れていると、直感に反することがあります。
  • ビルド対象のシステムに CMake をインストールする必要があります。
  • ビルド済みのバイナリがない場合は、しっかりした C++ コンパイラが必要です。

実際、ここで何を選択するかは、目標によって決まるはずです。

  • 有効なバイナリを生成するために、多くの壊れたツールチェーンに対処する必要がありますか? はいの場合は、上記の欠点を認識して、Autotools を検討することをお勧めします。CMake はこの多くに対処できますが、Autotools ほど心配する必要はありません。SCons を拡張して心配することはできますが、すぐに使える答えではありません。
  • Windows のターゲットについて心配する必要はありますか? もしそうなら、Autotools は文字通り実行されていないはずです。もしそうなら、SCons は良い選択かもしれませんし、そうでないかもしれません。もしそうなら、CMake は堅実な選択です。
  • クロスコンパイルについて心配する必要がありますか (ユニバーサル アプリ/ライブラリ、Google Protobufs、Apache Thrift など。これを気にする必要があります...)? その場合、AutotoolsはWindows について心配する必要がない限り、これらの機能は役に立ちますが、状況が変化するにつれて、構成システムの保守に多くの時間を費やすことになります。SCons は、Scratchbox2 を使用していない限り、現時点ではほとんど使用できません。実際には、クロスコンパイルのハンドルがなく、その拡張性を使用して、あなたはAutomakeでそうするでしょう。その場合、CMake を検討することをお勧めします。CMake は、サンドボックスからの漏えいを心配することなくクロスコンパイルをサポートし、Scratchbox2 のようなものを使用しても使用しなくても動作し、OpenEmbedded などとうまく統合できるからです。

多くのプロジェクトが qmake や Autotools などを捨てて CMake に移行しているのには理由があります。これまでのところ、CMake ベースのプロジェクトがクロスコンパイルの状況または VisualStudio のセットアップに落ちるか、プロジェクトが Windows のみまたは OSX のみの部分を考慮していないため、少量のクリーンアップのみが必要になることを明確に期待できます。コードベースに。SConsベースのプロジェクトからそれを期待することはできません-そして、1/3以上のAutotoolsプロジェクトが何か間違っていると完全に予想しています.

于 2013-08-17T17:37:01.510 に答える
81

誰がツールを使用するかを明確に区別する必要があります。Cmake は、ソフトウェアをビルドするときにユーザーが使用する必要があるツールです。autotools は、SuS 準拠システムで利用可能な標準ツールのみを使用してソフトウェアを構築するために使用できる配布 tarball を生成するために使用されます。つまり、autotools を使用してビルドされた tarball からソフトウェアをインストールする場合は、autotools を使用していません。一方、Cmake を使用するソフトウェアをインストールする場合は、Cmake を使用しているため、ソフトウェアをビルドするには Cmake をインストールする必要があります。

大多数のユーザーは、ボックスに autotools をインストールする必要はありません。歴史的に、多くの開発者が、autoconf を実行して構成スクリプトを再生成することをユーザーに強制する不正な形式の tarball を配布しているため、多くの混乱が引き起こされてきました。これはパッケージング エラーです。ほとんどの主要な Linux ディストリビューションは、デフォルトではいずれのバージョンもインストールすべきではないのに、複数のバージョンの autotool をインストールするという事実によって、さらに混乱が生じています。開発者が tarball を構築するのではなく、バージョン管理システム (cvs、git、svn など) を使用してソフトウェアを配布しようとすると、さらに混乱が生じます。

于 2012-04-28T13:26:26.310 に答える
29

それは GNU コーディング標準に関するものではありません。

autotools の現在の利点 (特に automake と併用した場合) は、Linux ディストリビューションの構築と非常によく統合されることです。

たとえばcmakeでは、常に「必要なのは-DCMAKE_CFLAGSですか、それとも-DCMAKE_C_FLAGSですか?」です。いいえ、どちらでもありません。「-DCMAKE_C_FLAGS_RELEASE」です。または -DCMAKE_C_FLAGS_DEBUG。紛らわしいです-autoconfでは、./configure CFLAGS="-O0 -ggdb3" だけで、あなたはそれを持っています。

ビルド インフラストラクチャとの統合では、scons には使用できないという問題があります。この場合はmake %{?_smp_mflags}、_smp_mflagsおおよそ (管理者が設定できる) システム電源に展開される RPM マクロです。人々は -jNCPUS のようなものを環境を通してここに置きます。scons が機能していないため、scons を使用するパッケージは、組み込みのディストリビューションでのみシリアル化される場合があります。

于 2010-11-22T03:04:33.523 に答える
19

Autotools について知っておくべき重要なことは、Autotools は一般的なビルド システムではないということです。Autotools は GNU コーディング標準のみを実装しています。すべての GNU 標準に準拠したパッケージを作成したい場合、Autotools は優れたツールです。そうでない場合は、Scons または CMake を使用する必要があります。(たとえば、この質問を参照してください。) このよくある誤解が、Autotools に対する不満のほとんどの原因です。

于 2010-11-02T07:58:11.363 に答える