3

リリース、デバッグ、共有ライブラリ、実行可能ファイルなど、さまざまなバージョンにコンパイルする C++ プロジェクトがあり、それぞれに異なるコンパイラ フラグが設定されています。Make の代わりに Jam を試しています。Jam の方がシンプルなシステムに見えるからです。

ジャムはこれができますか？主な問題は、常に .o ファイルをソース ファイルと同じフォルダーに配置するため、複数のバージョンをビルドするときにそれらを上書きすることです。

アップデート

うまくいくと思われる解決策を見つけました。このファイルを使用して、ライブラリまたは実行可能ファイルのデバッグおよびリリース構成をビルドできます。

リリース ライブラリをビルドするコマンド:

jam -s config=lib -s release=1

のみを入力jamすると、デバッグ実行可能ファイルがビルドされます。Jamfile は次のとおりです。

FILES = 
    main.cpp 
    ;

BASENAME = steve ;
OBJ = obj ;

if $(release) 
{
    OBJ = $(OBJ)r ;
} 
else 
{
    DEFINES += DEBUG ;
    OBJ = $(OBJ)d ;
}

if $(config) = lib 
{
    OBJ = $(OBJ)_lib ;
    OUTFILE = lib$(BASENAME).so ;
    DEFINES += SHARED_LIBRARY ;
    LINKFLAGS += 
        -shared -Wl,-soname,$(OUTFILE) -fvisibility=hidden -fPICS 
    ;
} 
else 
{
    OUTFILE = $(BASENAME) ;
}

LOCATE_TARGET = $(OBJ) ;
MkDir $(LOCATE_TARGET) ;
Main $(OUTFILE) : $(FILES) ;
4

3 に答える 3

2

私は Perforce の Jam には詳しくありませんが、bjamではこれが可能です - そしてそれは簡単です。 bjamソースと同じディレクトリに中間ファイルを配置しません。ビルドしているプロジェクトのタイプに応じて、debug/release/static/shared ディレクトリを作成します。

たとえば、ライブラリのリリース バージョンとデバッグ バージョンをビルドし、それを静的にビルドする場合は、次のようにします。

bjam debug release link=static

bjamいくつかの癖がありますが、非常に効果的であることがわかりました。現在、msvc (8.0 および 9.0)、x86 の gcc 4.3、ARM の gcc 3.4、および PowerPC の gcc 4.3 を使用してシステムをビルドするために、(ほぼ) 同一のビルド スクリプトを使用しています。非常に素晴らしい。

于 2009-03-09T08:22:40.643 に答える
1

はい、これが可能です。これは「バリアント」と呼ばれ、boost.build には「debug」と「release」が事前定義されています。独自の「機能」を追加することもできます。それらをリンク非互換として定義すると、生成されたオブジェクト ファイルが別のサブディレクトリに配置されます。

機能の魔法: オフ オン: 伝播されたコンポジット。

feature.compose on : USE_MAGIC;

共存するバリアントを容易に維持できることは、boost.build の最も強力な機能の 1 つです。また、プロジェクト階層 (ライブラリを必要とするアプリケーションなど) を維持することも非常に簡単です。これは、ディレクトリへの再帰によってではなく、ファイル レベルで行われるため、並列ビルドが非常に効率的になります。

于 2009-03-09T08:26:36.500 に答える
-1

ビルド システムの人気は重要です。これは、組織内のより多くの人々 (および将来の従業員) がそれを知り、サポートできる可能性が高いことを意味するためです。

私はそれをしないと言うでしょう。ジャムは使用しないでください。とにかく、ブースト以外の誰かがそれを使用しますか？たとえば、Ant ははるかに人気のあるシステムであり、習得も容易だと思います。組織に恩恵をもたらし、ジャムには触れないでください。

于 2009-03-09T00:07:56.340 に答える