20

私はsconsを調べていますが、脳細胞の塊をまったく別のものに投資する前に、代替手段が何であるかを確認したいだけです. 私は過去に GNU make を使用していましたが、特に満足したことはありません。

特に: Ant が C / C++ プロジェクトでより頻繁に使用されないのはなぜですか? ( Ant cpptasksがあることを考えると) Ant は (明らかに) Java 指向であるという投稿をいくつか読みましたが、そうすることの欠点は何ですか? なぜ、scons は make よりもはるかに優れているのでしょうか?

私は TI DSP 用のクロス コンパイラを使用しています。通常、プロジェクトには 20 ～ 50 個の cpp ファイルがあります。ビルド管理で難しいのは、依存関係の自動チェックです。それ以外はすべて、一連のコンパイラ オプションと共にファイルのリストをマッピングするだけです。

編集:そして、なぜクロスコンパイルは何かを変えるのですか? これは gcc と同じように実行するコンパイラですが、私の PC では実行できないオブジェクト ファイルや実行可能ファイルを生成するだけです。

4

5 に答える 5

25

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

Ant には、基本的にバニラの Make と同じくらい良いか悪いかという欠点があり、C または C++ の特に主流ではないものを使用しているという追加の欠点があります。Cファイルからヘッダーファイル、ライブラリまたは実行可能ファイルなどの内部依存関係と、サードパーティのライブラリとリンクする必要があるなどの外部依存関係の両方で、すべての独自の依存関係に対処する必要があります。さらに、Ant C のタスクがそれほど維持されているとは思いません。Ant for C を使用しているのを見た人は皆、exec タスクで GCC を呼び出すことを推奨しています。

SCons の方が優れていますが、クロス コンパイルは得意ではありません。CMake や Autotools のような「ビルド システム」でもなく、単なるビルド ツールです。彼らのwikiにあるように、それはほとんど「Make in Python」です。ただし、依存関係の処理が組み込まれています。つまり、「gcc -MM -MD」などを使用して自分でロールバックする必要がないため、Make よりも有利です。SCons は、インストールされているサードパーティ ライブラリの検出もサポートしていますが、通常の方法ではビルド時間が大幅に長くなる可能性があります。他のシステムとは異なり、SCons は実行するたびにチェック ステージを実行しますが、ほとんどの結果はキャッシュされます。SCons はビルド時間が長いことでも有名ですが、ファイルが 50 個あれば問題ありません。メーリング リストのこのスレッドで議論されているように。通常、ビルドを 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、

編集者向け: クロス コンパイルは、プログラムとライブラリの自動検出が複雑になるため、ビルド システムでは特に頭の痛い問題です。SCons はこの問題に対処しません。それはあなた次第です。Ant も同様に何もしません。Autoconf は autotools の場合にこれを処理しますが、構成時にコマンド ラインで「--with-libfoobar=/some/path」を指定する必要がある場合や、リンク フェーズで /usr/lib を使用しようとするとリンクが壊れる場合があります。 . CMake のアプローチは、ツールチェーン ファイルを使用すると少し重くなりますが、すべてのツールとライブラリ (CC、CXX、RANLIB、-with-ibfoo= など) を指定する必要がないことを意味します。標準的なコンベンション。理論的には、適切に作成された CMake ツールチェーン ファイルを複数のプロジェクトで再利用して、それらをクロス コンパイルできます。

于 2009-06-23T20:58:58.633 に答える
6

私は数年前、JNI を介して新しい Java コードに統合される非常に大規模なコード ベースを構築するために Ant+CppTasks を多用しましたが、C++ コードの非常に信頼性の高いインクリメンタル ビルドの結果、優れた柔軟性 (ビルド ファイル、またはコードの微調整を介して）。しかし、CppTasks はコミュニティのないプロジェクトであり、メンテナー (Curt Arnold) は長い間何もしていません。それは非常に優れた有用なままですが、CppTasks を知っているか使用している人はほとんどいないことに注意してください (たとえば、C ファイル用の特定のコンパイラが必要で、別の C++ コンパイラがこれらを拾っていたときに、コンパイラがファイルを「ビッド」する方法が私を苦しめました)。代わりは）。

CppTasks がコンパイル オプションを追跡し、ヘッダーの依存関係についてソースを動的にスキャンする方法は、常に十分に高速であり (依存関係のキャッシュがいくつかあります)、正確なインクリメンタル ビルドを備えた唯一のシステムを意味しました。非常に大規模なコード ベースの構築。

Ant ユーザー/開発者リストで何度か述べたように、Java 関連のものがたくさんあり、既に Ant に投資していて、ドキュメントやCppTasks のコードに飛び込むことを恐れていない場合は、 JNI「グルー」コード、および/またはグルーコードが公開する「レガシー」ネイティブライブラリを構築する必要があり、それは価値のある競争相手であり、報酬は素晴らしいものになる可能性があります.

Windows dll の <rc> を簡単に統合して、完全なバージョン情報を追加しました。たとえば、.res ファイルを正しくフォーマットするための小さな Ant タスクを作成しました。それは私にとってはうまくいきましたが、Ant + CppTasksは間違いなく「高度な」Antユーザー/開発者向けです。

これが役立つことを願っています。--DD

于 2009-06-24T17:26:20.647 に答える
3

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

terpは、依存関係分析を使用した増分ビルドではなく、主に完全な再構築用に設計されています。そこに着きましたが、まだそこにはありません。terpのスイートスポットは、マルチプラットフォーム、マルチプロシージャ、マルチコンパイラのリリースであり、すべての組み合わせに対してn個の異なる構成を維持する必要はありません。この時点（2009年7月）ではパブリックベータ版ですが、まもなくリリースされる予定です。

于 2009-07-13T19:08:40.410 に答える
2

過去 5 年間、ant を使用して x86 とアーム ビルドを行うプロジェクトに取り組んできました。arm-gum-linux-gnueabi- などの接頭辞を渡すだけで、g++ や ar などの実際のツールの先頭に追加される汎用コンパイラを生成する目的で cpptasks を微調整しました。プレフィックスがないということは、開発プラットフォームのビルド ツールを入手できることを意味します。クロス コンパイル用のツールチェーンには、ビルド ツール バイナリにこれらのプレフィックスがあります。make ベースのものではなく、Ant を使用する理由のほぼすべては、cpptasks のインクリメンタル ビルドを実行する機能と、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>
于 2011-09-23T06:04:17.823 に答える
1

Ant のユーザーベースは非常に Java に依存しています (当然の理由による)。Ant が非常に幅広い設定で非常に役立つという事実は、ほとんどの非 Java 開発者が気づいていないことです。その結果、Ant を使用して C/C++ コードをビルドする場合は、より大きなユーザー ベース (CMake または SCons) を持つシステムを使用する場合よりもはるかに多くのことを自分で行うことができます。

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

CMake のクロスコンパイルのサポートを「成熟した」と呼ぶかどうかはわかりません。まだかなり若いからです。でも CMake の人たちは真剣に取り組んでいるので、ためらわずに試してみたいと思います。

于 2009-06-24T10:15:15.443 に答える