1

私は最近、クロス プラットフォーム ビルド システム (メイク ファイル、ビジュアル スタジオ ソリューション/プロジェクトなどをオンデマンドで生成する) を使用して独自のライブラリとプロジェクトのセットアップを開始しましたが、既に解決されている可能性が高い問題に遭遇しました。

私が遭遇した問題は次のとおりです。アプリケーションに依存関係もある依存関係がある場合、リンクされるアプリケーションは依存関係とそのすべてのサブ依存関係をリンクする必要があります。これは再帰的に進行します。

（議論のために、静的ライブラリのみを扱っていると仮定しましょう。）

  • TopLevelApp.exe
    • 依存関係_A
      • 依存_A-1
      • 依存_A-2
    • 依存関係_B
      • 依存関係_B-1
      • 依存関係_B-2

したがって、この例では、TopLevelApp は、dependency_A、dependency_A-1、dependency_A-2 などをリンクする必要があり、B についても同様です。ターゲット アプリケーションでこれらすべてを手動で記憶する責任は、最適ではないと思います。また、依存関係の同じバージョンがすべてのターゲットで使用されることを保証するという問題もあります (一部のターゲットが同じものに依存していると仮定すると、boost など)。

現在、すべてのライブラリをリンクする必要があり、それを回避する方法はありません。私が探しているのは、これを管理するビルド システムです。したがって、何かに依存することを指定するだけで、そのライブラリの適切な依存関係が自動的に取り込まれます。

私が調べているビルドシステムは、これを処理しない premake premake4です(私が判断できる限り)。これを処理するビルドシステムを知っている人はいますか? ない場合は、なぜですか？

4

1 に答える 1

1

これが処理される一般的な方法は、依存しているライブラリに、それが何を必要とし、どのバージョンに対してリンクされているかを教えてもらうことです。これを行う1つの方法は、pkg-configを使用することです。たとえば、pkg-config name_of_package --cflagsを呼び出すと、間接的な依存関係のヘッダーを追加するために必要なフラグを含む必要なフラグが出力されます。同様に、pkg-config name_of_package --ldflagsは、その特定のライブラリとその依存関係を含む必要なリンカーフラグを出力します。ビルドシステムに関しては、CMakeを使用することをお勧めします。CMakeでは、依存関係はFIND_PACKAGE（name_of_package）の呼び出しによって検出されます。これにより、パッケージが見つかった場合は変数name_of_package_FOUNDが1として定義され、見つかった場合は、ライブラリとヘッダーパスに対してname_of_package_LIBRARIESとname_of_package_INCLUDE_DIRSが定義されます。そのパッケージだけでなく、その依存関係のライブラリとヘッダーにも適用されます。とはいえ、FIND_PACKAGEメカニズムは、サードパーティによって作成されたプラガブルモジュールを介して機能するため、システムは、依存関係の依存関係が再帰的に含まれるように_LIBRARIES変数と_INCLUDE_DIRS変数を設定することになっていますが、最後にチェックしたときに、すべてのモジュールがこれを正しく行うわけではありません。

于 2010-05-17T03:43:06.760 に答える