Ninja: 相対的なサブ忍者のパスは解決されません

すべてのパスは、subninja行を含むファイルではなく、ビルドディレクトリを基準にしています。

しかし、それは意味がありません。 つまり、ジェネレーターは、ファイルのプレフィックスを付加する方法を_すべて_実装する必要があります。つまり、実行される作業ディレクトリコマンドを変更する必要があります（ジェネレーター/コマンドの実行方法によっては、ビルド構成の元の意図が変わる可能性があります）。

では、 subninjaとincludeのユースケースは対照的ですか？

ビルドファイルに相対的なパスを持つサブ忍者は、独自のディレクトリ内で実行するように構成された依存関係がパスを変更せずに実行できるという点で役立ちますが、親忍者構成の依存関係グラフに貢献できます。

includeの機能は変更されず、ルール名が結合された名前空間に含まれることを除いて、サブ忍者の動作とまったく同じように動作します（＃921のとおり）。 現在、 subninjaとincludeは、変数とルール名のスコープを除いて、基本的に同じことを実現しています...

ジェネレータはすべての.ninjaファイルを生成するため、ビルドディレクトリに相対的なパスを書き込むことができます。 さまざまなジェネレーターによって生成された忍者ファイルを組み合わせるのは興味深いアイデアですが（それはあなたがやりたいことのように聞こえますか？）、それは現時点でサポートされているものではありません。

正解ですsubninjaとincludeの違いは、前者はスコープを追加し、後者はスコープを追加しないことです。 このユースケースは、トップレベルの忍者がcflagsなどの変数を参照するccなどの一般的なビルドルールを定義でき、各サブ忍者がcflagsをそのターゲットに適切なものに設定できることです。そこでは1回限りのアクションになる可能性があります。 例を見るには、python misc / write_fake_manifests.py / tmp / foo`を実行して、このパターンを使用する一連の.ninjaファイルを/ tmp / fooに書き込むことができます。

それは理にかなっていますが、（範囲以外の）メリットはまだあまりありません。

さまざまなジェネレーターによって生成された忍者ファイルを組み合わせるのは興味深いアイデアです（それはあなたがやりたいことのように聞こえますか？）

その通り。 ジェネレーターのサブモジュールとしてNinja自体を含め、次に別のCMakeプロジェクト（Ninjaビルドファイルを出力するように構成されている）を含め、両方のNinja構成ファイルを生成してsubninjaとして含めることができます。 _my_プロジェクトのbuild.ninjaファイルを使用して、それらを単独でビルドできるようにしますが、プロジェクト全体を一度にビルドするために、プロジェクトがそれらの出力（したがって依存関係グラフ）を使用できるようにします。 。

それが理にかなっている場合。 特に私のジェネレーターで見られる直接のユースケースは、N個のサブプロジェクトをすべて独自のbuild.ninjaで含めることができるという点で、Tup（IIRCがNinja自体の設計上の決定に影響を与えた）からいくつかの概念を借用していることです。ファイルを作成し、それらのグラフを利用して、はるかに大きな依存関係グラフを自動的に作成できるようにします。

個人的には、 subninjaの方がはるかに便利だと思いますが、それが潜在的に壊滅的な変化であることがわかりました。 ただし、1）依存関係のbuild.ninjaファイルをパッチで変更するか、2）依存関係の依存関係グラフを利用する機能を犠牲にしない限り、これを回避する方法はわかりません。

考え？

どうですか：

subninja path/to/build.ninja relative path/to

存在しないrelative 、デフォルトで./なります。 それはそれを壊さないようにしますが、ジェネレーターがそう望むならそれでも機能を与えます。

または、他の忍者構成の手順に従って、多分

subninja path/to/build.ninja
  relative = path/to

... / fooにプロジェクトがあり、サブディレクトリバーがあり、Ninjaに提案した相対パスロジックがあるとします。

ビルドシステムがすべてのビルド出力を/ foo / objに書き込みたい場合、ディレクトリ相対パスを使用した/ foo / barのサブニンジャは、出力を../obj/barに書き込むことを知っている必要があります。そのサブディレクトリからのファイル。 したがって、build.ninjaファイルを生成するものはすべて、グローバルパス階層をすでに認識している必要があります。この場合、すべてのパスを相対化することは、bar /ディレクトリ内のパスの前にbar /を追加することと実質的に同じ問題です。

ただし、ソースディレクトリにビルド出力を書き込む人は十分にいるので、上記は関係ありません。 私は主に、さらに強力な分離を望んでいる人々から聞いています。たとえば、忍者にパッチを送信して、完全に無関係なディレクトリにビルド出力を使用して忍者をビルドできるようにした人々などです。

私は上手く理解できていない気がします。 サブ忍者は、特に私が説明したユースケースでは、通常、親忍者の構造については知りません（少なくとも、知る必要はありません）。 とはいえ、誰かがそうするケースを見つけることができると確信しています。

私が今直面している問題は、ジェネレーター（100％）を使用しない依存関係（サードパーティライブラリなど）は、現在ブートストラッパーを使用して構築する必要があり、毎回ブートストラップする必要があることです。 '更新または変更など。私が使用しているほとんどのジェネレーターには、忍者構成に出力するオプションがありますが、それらはすべて、そのディレクトリのみ（つまり、そのディレクトリに対して）に構成されています。

構成とグラフを使用して選択的な再構築を実行できることは非常に大きなことです。 現在、 subninjaはビルドディレクトリに相対的なパスを想定しているため、これを行うことはできません。

エヴァン：私がこれを理解した方法は、次のようなツリーを作成するということです。

  subbuild1
  subbuild2

ジェネレータは通常、ビルドディレクトリを任意の場所に配置することをサポートしているため、サブビルド1にプロジェクト1をビルドし、サブビルド2にプロジェクト2をビルドする必要があります。 次に、builddirにトップレベルの忍者ファイルがあり、Qix-はサブプロジェクトの構築を推進したいと考えています。

無関係：このrelative機能は、現在のディレクトリがビルドディレクトリと等しいことにルールが依存している場合（たとえば、ルールがビルドされたアーティファクトなどを削除する場合）、cwdを引数に変更する必要があります。