ant + cpptasks vs. scons vs. make

Question

私はsconsを探しています。私は脳細胞の塊を完全に異なるものに投資する前に、選択肢が何であるかを確認したいだけです。私は過去にGNU makeを使ってきましたが、これまで特に満足していませんでした。

特に：AntがC/C++プロジェクトでより頻繁に使用されるのはなぜですか？ （与えられたのはant cpptasksです）私は、AntのほうがJavaを中心にしていると言う記事をいくつか読んでいますが、そうすることの欠点は何ですか？そしてなぜsconsは作るよりもずっと優れていますか？

私はTI DSP用のクロスコンパイラを使用しています。通常、プロジェクトには20〜50個のcppファイルがあります。ビルド管理の難しい部分のように思えるのは、自動依存性チェックです。他のすべては、コンパイルオプションのセットとともにファイルのリストをマッピングするだけです。

編集：なぜクロスコンパイルで変更されますか？ gccが実行するのと同じ方法で実行されるコンパイラです。私のPCで実行されないオブジェクトファイルや実行ファイルを生成するだけです。

Answer 1

クロスコンパイルの場合は、CMakeまたはAutotoolsのいずれかを選択することをお勧めします。特に、複数のアーキテクチャ/プラットフォーム用にコードをコンパイルできる場合私は、通常、ユニットテスト目的のためにネイティブマシン上で自分のコードのサブセットをコンパイルし、ターゲットプラットフォーム用にそのすべてをコンパイルします。 CMakeはこれを特にうまく処理します。これは、クロスコンパイルされたライブラリがどこにあるのかを指定できるようにするためです。したがって、/ usr/libにあるクロスコンパイルされたlibpngを検索するのではなく、/ opt/arm-eabi-gcc /またはビルドマシンにツールチェーンライブラリがインストールされている場所を調べるように指示することができます。さまざまなバリアントに複数のビルドディレクトリを作成し、それぞれのバリアントをmakeで手動でコンパイルするか、braindeadで手作業で再帰的にmakeを実行することができます。

Antには、基本的にはバニラのMakeと同じか悪いという欠点があります.CやC++では特に主流ではないという欠点があります。ライブラリや実行可能ファイルへのヘッダファイルへのCファイルやサードパーティのライブラリとのリンクなどの外部依存関係のような、あなた自身の依存関係をすべて処理する必要があります。私はAnt Cのタスクが実際にそれほど維持されているとは思わない。私が見てきたすべての人は、GCCにexecタスクを呼び出すCの支持者のためにAntを使用しています。

SConsは優れていますが、クロスコンパイルはその強みではありません。 CMakeやAutotoolsのような "ビルドシステム"ではなく、ビルドツールだけです。それは彼らのwikiで言う通り、it is pretty much "Make in Python"です。それは依存関係の処理を組み込んでいます。つまり、 "gcc -MM -MD"などで自分自身をロールする必要がないので、Makeよりも利点があります。 SConsは、インストールされているサードパーティのライブラリを検出する機能もサポートしていますが、通常行われている方法でビルド時間を大幅に増やすことができます。他のシステムとは異なり、SConsは実行するたびに検査段階を実行しますが、ほとんどの結果はキャッシュされます。 SConsは長いビルド時間でも悪名高いですが、問題ではない50個のファイルについてはそうです。 SConsでのクロスコンパイルのサポートは存在しません。あなた自身をロールバックする必要があります。as discussed on this thread on the mailing list通常、ビルドをUnixプラットフォームのように強制してから、Cコンパイラの名前を上書きします。複数のバリアントをビルドするか、ビルドディレクトリをソースディレクトリから分離するのは難点です。コードをクロスコンパイルし、ネイティブにコンパイルするとあまり適切ではありません。

CMakeとAutotoolsの依存関係の問題は非常によくわかっており、autotoolsのクロスコンパイルのサポートは成熟しています。 CMakeは2008年4月にリリースされたバージョン2.6.0からクロスコンパイルしています。これらの機能は無料で、パッケージングやユニットテスト（make checkや同様のターゲット）のようなものもあります。これらのツールの両方の欠点は、ブートストラップが必要なことです。CMakeの場合は、MakefileまたはVisual Studioのソリューションファイルを作成するためにCMakeバイナリをインストールする必要があります。 Autotoolsの場合、ソフトウェアをコンパイルするすべての人にautomakeとautoconfがインストールされているわけではなく、ビルドシステムを変更する必要がある人のみ（ビルドシステムの変更として新しいファイルを追加する） 2段階のブートストラップ（configure.ac - > configure、configure + Makefile.in - > Makefile）は概念的に分かりにくいです。

編集のため：クロスコンパイルは、プログラムとライブラリの自動検出に複雑さを増やす理由から、ビルドシステムでは余計な頭痛です。 SConsはこの問題に対処していません。 Antは同様に何もしません。 Autoconfはautotoolsの場合にこれを処理しますが、リンクフェーズで/ usr/libを使用しようとすると、リンクが壊れたりリンクが途切れたりすると、コマンドラインに "--with-libfoobar =/some/path" 。 CMakeのアプローチはtoolchainファイルのほうが少し重いですが、あなたが考え出したツールとライブラリ（CC、CXX、RANLIB、--with-ibfoo =など）をすべて指定する必要はありません標準的な慣習である。理論的には、適切に細工されたCMakeツールチェインファイルを複数のプロジェクトで再利用してクロスコンパイルすることができます。実際にはCMakeは一般的なハッカーにとってこれを便利にするのに十分ではありませんが、複数のプロプライエタリなプロジェクトを作成する場合には便利です。

Answer 2

Antは非常にJavaベースのユーザーベースです（自然な理由から）。 Antの方がはるかに広い設定で非常に便利であるという事実は、Java以外の開発者のほとんどが気づいていないものです。その結果、C/C++コードをビルドするためにAntを使用する場合、より大きなユーザーベース（CMakeまたはSCons）を持つシステムを使用する場合は、自分でもっと多くのコードを作成します。

個人的に私はCMakeに本当に満足しています。なぜなら、主に実際のVisual Studioプロジェクトを生成できる唯一のビルドシステムだからです。 SConsも可能ですが、SConsは外部呼び出しを行いますが、CMakeはVisual Studio独自のビルドエンジンを使用するプロジェクトを生成します。これはVisual Studioに慣れている人と一緒に作業している場合に非常に便利です。

私はCMakeのクロスコンパイルのサポートを "成熟"と呼んでいるかどうかはまだ分かりません。しかし、CMakeの人々はそれについて真剣ですので、私はそれを試してみることを躊躇しないでしょう。

Answer 3

非常に大きなコードベースをJNI経由で新しいJavaコードに組み込むために数年前からAnt + CppTasksを使用してきましたが、C++コードの非常に信頼性の高いインクリメンタルビルドの結果、ビルドファイル内、またはコードの調整など）。しかし、CppTasksはコミュニティのないプロジェクトであり、メンテナー（Curt Arnold）は長い間何もしていません。 CppTasksを知っている人やCppTasksを知っている人はほとんどいないことに注意してください。（たとえば、コンパイラがファイルに対して "入札"をする方法は、私がCファイル用に特定のコンパイラを必要としたときなどです。代わりに）。

CppTasksはコンパイルオプションを追跡し、ヘッダ依存関係を常に動的にスキャンします（依存関係のキャッシュがあります）。これは正確なインクリメンタルビルドを持つ唯一のシステムで、非常に大きなコードベースを構築する際には非常に重要なことです。私はあなたがJava多くのものを持っており、すでにAntの投資を持っている場合、Antのユーザーは/ devリストの数回は、とはDOC にダイビングを恐れていないと述べてきたように

と CppTasksのコードで、JNIの "グルー"コードやグルーコードが公開する "レガシー"のネイティブライブラリをビルドする必要があります。これは価値のある候補です。私は簡単に完全なバージョン情報を追加するために、WindowsのDLLのRC > <を統合

、例えば、.RESファイルを正しくフォーマットするために少しのAntタスクを書いて。それは私のために働いたが、Ant + CppTasksは、 "高度な" Antユーザー/開発者IMHOの方がはるかに多い。

こちらがお役に立てば幸いです。 --DD

Answer 4

ANTからC++プロジェクトをビルドする場合は、terpをお勧めします。 ANTは私たちの選択したビルドツールであり、CppTasksは少し長くなっていて、別のレベルの抽象化で作業したいので、私たちはterpを開発しました。 terpは多くの異なるコンパイラをサポートしており、当社でサポートしています。ほとんどのプロジェクトでは無料ではありません。

私たちは、依存解析を伴うインクリメンタルビルドではなく、完全なリビルドのために主に設計しました。私たちはそこに着いていますが、まだそこにはありません。テルプのスイートスポットは、マルチプラットフォーム、マルチプロッカ、マルチコンパイラのリリースで、すべての組み合わせに対してn個の異なる設定を維持したくない場合です。この時点（2009年7月）に公開されていますが、すぐにリリースされます。

Answer 5

私は、過去5年間にx86を実行し、antを使用してアームをビルドするプロジェクトに取り組んできました。私たちは、arm-gum-linux-gnueabi-のような接頭辞を渡すジェネリックコンパイラを生成するためにcpptasksを微調整し、g ++やarなどの実際のツールの前に追加します。接頭辞は、開発プラットフォーム構築ツールを入手することを意味しません。クロスコンパイル用のツールチェーンには、ビルドツールのバイナリにこれらの接頭辞が付いています。何かが起きるのではなく、Antを使っている理由のほとんどは、元気なビルドを行う能力と、autoconfを幸せに保つために起こらなければならないようなものです。ほぼすべてのソースファイル、特にライブラリセットのフォルダツリー構造のソースファイルを作成/名前変更/削除することができ、ビルドファイルを編集する必要がないというパラダイムをサポートすることができます。 1つの小さな欠点は、ファイルをリンクすることにより不必要な再構築を引き起こすような方法でプロパティを更新することです。

<target name="lib.cvp"> 
<fetch.and.log.version 
    svnvers.target="common/cvp" 
    svnvers.property="libcvp.version"/> 
    <cc objdir="${obj.dir}/common/cvp" 
     commandPrefix="${command.prefix}" 
     compilerName="${compiler.name}" 
     outfile="${lib.dir}/cvp" outtype="static"> 
     <compiler extends="base.compiler"/> 
     <compilerarg 
      value="-D__CVP_LIB_BUILD_VERSION__=&quot;${libcvp.version}&quot;"/> 
     <compilerarg 
      value="-D__BUILD_NOTES__=&quot;${libcvp.toolversion}&quot;"/> 
     <compilerarg if="is.x86" value="-DARCH_X86"/> 
     <linker extends="base.linker"/> 
     <includepath refid="common.inc"/> 
     <fileset dir="${project.home}/common/cvp"> 
      <include name="*.c"/> 
      <include name="*.cpp"/> 
     </fileset> 
    </cc> 
</target>