Cc： @nico @chaoren

CMakeで、 16675号、13894号、およびMR520に関連する議論があります。

回避策として、「。」でもオブジェクト出力ディレクトリを明示的に設定できます。 または「..」ですが、絶対パスも機能します。
ninjatst.bash.txt

@zlolik IIUCは、ビルドマニフェスト（ build.ninja ）グラフノードに絶対パスを配置することをお勧めします。 確かにそれは機能します（そしてCMakeがアウトオブソースビルドで行うことです）が、ここでの私のポイントは、Ninjaは絶対パスの使用を推奨していませんが、IDEは出力で絶対パスを必要とします。

また、 -c foo.cを指定したコンパイラが、とにかくdepfileに絶対パスを生成する可能性もあります。 その場合、ここで報告されているのと同じ問題があるため、Ninjaは依存関係を認識しません。

これを修正するには、Ninjaが相対パスと絶対パスが同じファイルであり、内部に2つではなく1つのグラフノードしかないことを認識できるようにする必要があります。 build.ninjaジェネレーターにビルドマニフェスト内で一貫してパスに名前を付けるように依頼するのが合理的であるため、これはdepfile処理に対してのみ行うだけで十分な場合があります。

@bradkingまず、忍者に問題があることに同意します。回避策を提案するだけです。
私は3つの関連する問題があると思います：

1. 入力絶対/相対パスを使用したロジック。詳細については、＃1152を参照してください。
2. 出力の絶対パス/相対パスを強制するロジック。 コンパイラの問題-出力に​​絶対パスが必要であるとコンパイラに伝える唯一の方法は、コマンドラインで絶対パスを使用することです。 忍者の問題ではなく、私たちの問題です。
3. depfileの絶対パス/相対パスを解析するロジック。 この問題。

私は2つの回避策を使用します：

1. 最初の2つの問題を解決するには、 build.ninjaジェネレーターのパスにプレフィックス$pと$oを使用します。 私の場合、 $pと$oは絶対的なものではなく、 build.ninjaジェネレーターが実行された現在のディレクトリからの相対的なものです。
2. スクリプトを使用して、depfileをninja互換パスに変換します。 一部のコンパイラでは、depfileを生成するために個別の呼び出しが必要です。 ただし、絶対パスの問題はありません。

参考までに、提案された解決策を使用してninja-buildメーリングリストのスレッドを開始しました。

デバッグおよびカバレッジ情報に関する別の関連する問題：相対パスでコマンドを使用すると、相対パスでデバッグ情報ファイルも作成されます。 問題は、デバッグファイルは通常、ソースファイルではなくオブジェクトファイルの隣に配置されるため、そこにある相対パスが存在しないファイルを参照することです。

これに関する更新はありますか？ メーリングリストのスレッドに応答がありません...

こんにちは、みんな、

また、 -c foo.cを指定したコンパイラが、とにかくdepfileに絶対パスを生成する可能性もあります。

IAR v8の依存関係ファイルには、絶対パスのみが含まれています。

CMake / Ninja / IARでアウトオブソースビルドを実行すると、この問題が発生します。CMakeのバイナリディレクトリで終了する生成ファイルは、Ninjaマニフェストでは相対的であり、IARによって出力されるdepsは絶対的です。

私にとって、これは明らかに忍者の問題です。同じファイルに対して2つのノードが存在するべきではありません。

@bradkingの提案を読みましたが、シンボリックリンクに関する部分とgetcwd()が使用できない理由をよく理解していません。 詳しく説明していただけませんか。

シンボリックリンクの部分と、 getcwd()が使用できない理由がよくわかりません。

@sebknzl問題は、ジェネレータによってbuild.ninjaに書き込まれる絶対パスに、何らかの理由で意図的に解決されていないシンボリックリンクが含まれている可能性があることです。 getcwd()は通常、シンボリックリンクが解決されたパスを返します。 Ninjaがビルドマニフェストの相対パスまたはgetcwd()に相対的なdepfileを解釈する場合、Ninjaが構築する絶対パスは、ビルドマニフェストジェネレーターが使用したものと一致しない可能性があり、2つのノードになります。

リンクしたスレッドで提案するninja_workdirは、基本的に、ジェネレーターが相対パスのベースとして使用したものをNinjaに伝えることです。 実際には、 realpath(ninja_workdir) == realpath(getcwd())は常に真である必要がありますが、それはninja_workdir == getcwd()を意味するものではありません。 もう1つの方法は、Ninjaがノードを作成する前にすべてをrealpathすることですが、これは$inがジェネレーターの意図したとおりに拡張されないことを意味します。

@jhasseこの問題とそれに対処するための私の提案をご覧ください。

CMAKE_NINJA_GENERATOR_OPTION_によって制御される絶対パスで_build.ninja_を生成してみませんか？

つまり、このように機能します：

Claus-MBP:build clausklein$ cat build.ninja 

# project dir
p = /Users/clausklein/Downloads
# object dir
o = /Users/clausklein/Downloads/.ninjatst.build

rule cp
  command = cp $in $out

rule cc
  depfile = $out.d
  deps = gcc
  command = cc -I$o -c $in -o $out -MD -MT $out -MF $out.d

# All absolute paths works
build all: phony $o/foo.o

# All absolute paths works
build $o/foo.h: cp $p/foo.h.in
  IN = $p/foo.h.in

# All absolute paths works
build $o/foo.o: cc $p/foo.c || $o/foo.h
  IN = "$p/foo.c"

default all

Claus-MBP:build clausklein$ 

ninjatst.bash.txtで生成

@ClausKlein絶対パスを使用するようにCMakeに教えてみました。 https://github.com/ninja-build/ninja/issues/1251#issuecomment-282322776でリンクしたディスカッションを参照してください。 「ある場合を修正し、他の場合を壊すような別の方法で物事を行う」というオプションを追加したくありません。

これを適切に修正するには、 https： //github.com/ninja-build/ninja/issues/1251#issuecomment-487618865でリンクした提案のNinja機能が本当に必要です。

いいよ

それなら、mesonbuildシステムのこの修正も利用できますか;-)

午前12.03.2020um 12:56 schrieb Brad [email protected] ：

@ClausKleinhttps ：//github.com/ClausKlein絶対パスを使用するようにCMakeに教えてみました。 ＃1251（コメント） https://github.com/ninja-build/ninja/issues/1251#issuecomment-282322776でリンクしたディスカッションを参照してください。 「ある場合を修正し、他の場合を壊すような別の方法で物事を行う」というオプションを追加したくありません。

これを適切に修正するには、＃1251（コメント） https://github.com/ninja-build/ninja/issues/1251#issuecomment-487618865でリンクした提案のNinja機能が本当に必要です。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/ninja-build/ninja/issues/1251#issuecomment-598146822で表示するか、 https ：//github.com/notifications/unsubscribe-auth/AAN7QWWEDHMDA45DQVPLOUDRHDEVDANCNFSM4DBNL6GAの登録を解除してください。

忍者がdepfile情報の照合にninja_workdirを使用し、シンボリックリンクが原因でninja_workdir != getcwd()の状況が発生したとします。 コンパイラがgetcwd()を使用して絶対パスを出力するようになった場合はどうなりますか？

コンパイラは、それらが相対パスとして渡されない限り、 getcwd()を使用しないでください。相対パスとして渡された場合は、ビルドシステムジェネレータが責任を負う必要があります。

または、 ninja_workdirとgetcwd()の両方で正規化することを検討できます。

まあ、相対パスが与えられたとき、コンパイラはdepfileで絶対パスを返さないはずです;）

@ClausKlein絶対パスを使用するようにCMakeに教えてみました。 ＃1251（コメント）でリンクしたディスカッションを参照してください。 「ある場合を修正し、他の場合を壊すような別の方法で物事を行う」というオプションを追加したくありません。

@ClausKleinによって提案されたように、絶対パスを使用したときに正確に何が壊れましたか？

コンパイラに絶対パスが指定されている場合、コンパイラが生成するdepfileには絶対パスがあり、ビルドマニフェストのヘッダーへの相対パス（生成されたヘッダーなど）とは調整されません。 この号の冒頭にある私の最初の投稿のninja-bug.bash.txtリンクを参照してください。 それは何が起こるかの段階的な例を示しており、純粋に忍者の観点から表現されており、CMakeはありません。

読んだことがありますが、 https： //github.com/ninja-build/ninja/issues/1251#issuecomment -284533599を使用してみませんか？ 忍者が絶対的な道を「落胆させる」という理由だけで？ もしそうなら、これはドキュメントの変更についてですか？

build.ninjaファイルは、どこでも絶対パスを繰り返さなくてもはるかに小さいため、高速になります。 また、見栄えがよく、デバッグが容易で、シェルでのビルドターゲット名のタブ補完に適しています。 IMO忍者が作るのは良いお勧めです。 忍者はこの事件を和解させるためにもう少し情報が必要です、そしてそれは私が提案するものです。

@bradkingの相対パスは必ずしも短いとは限りません。

build jsoncpp@sha/src_lib_json_json_reader.cpp.o: cpp_COMPILER ../../../../../Users/clausklein/Workspace/cpp/jsoncpp/src/lib_json/json_reader.cpp
 DEPFILE = jsoncpp@sha/src_lib_json_json_reader.cpp.o.d
 ARGS = -Ijsoncpp<strong i="7">@sha</strong> -I. -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp/include -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp/dir1 -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp/dir2 -fdiagnostics-color=always -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O3

私の例https://github.com/ninja-build/ninja/issues/1251#issuecomment-597877775見栄えが良いです！

CMakeのジェネレーターには、ビルドツリーを離れる../シーケンスを使用しないというルールがあります。 完全にソース外のビルドでは、ソースツリーへの絶対パスとビルドツリー内の相対パスを使用します。 後者はビルドツリーの下にあるため、 ../で始まることはありません。

私は知っています、それは_mesonbuild_で生成されました。 ;-)

しかし、それよりも、ソースツリーへの生成を拒否してみませんか？

相対パスと絶対パスのメリットについては、永遠に議論することができます。 忍者はそれについて意見を述べるべきではありません。 ここでの問題は、両方が単一のビルド内で使用される場合の調整です。 ビルドシステムジェネレーターは、ツールがパスをどのように処理するかを常に制御できるとは限りません。 Ninjaは、同じファイルへの絶対パスと相対パスの混合をサポートする必要があり、提案で概説した簡単なアプローチでサポートできます。 やる気を起こさせるユースケースの場合、変更はdepfile解析に分離されます。

Ninjaは、同じファイルへの絶対パスと相対パスの混合をサポートする必要があります

同意します！

すべての説明をありがとう、私は理解し始めています。

Ninjaが（depfileで絶対パスに遭遇したときに）cwdとそれが見つけたパスの両方をrealpathするとしたらどうでしょうか？ 次に、realpatheddepfile-pathからrealpathedcwdを削除して、生成されたヘッダーと一致する相対パスを取得します。 それはうまくいくでしょうか？

getcwd()は常にリアルパスであるため、手順は必要ありません。 Ninjaがrealpath()の場合、depfileが提供する絶対パスを使用して、機能する可能性のあるcwdプレフィックスを確認します。 ただし、 realpath()はおそらく高価なシステムコールですが、私の提案したninja_workdirは、文字列処理を介して純粋にメモリ内のパスを調整できます。

他の方向への混合も許可する必要があります。ビルドマニフェストでは絶対パスですが、depfileでは相対パスです。 忍者がbuild.ninjaを解析している間、すべての絶対パスをrealpath()にする必要はないと思います。 それはおそらく遅いでしょう。

結果を使用して、workdirを決定できます。 例えば：

getcwd（）： /var/xyz/build
depfileエントリ： /home/foo/build/bar.h
realpath（depfileエントリ）： /var/xyz/build/bar.h
相対リアルパス： bar.h
depfileエントリからそれを削除します： /home/foo/build -> ninja_workdir

このように、realpathを1回呼び出すだけで済みます。

一般的に、 ninja_workdir自動的に導出することは不可能だと思います。 元のシンボリックリンクを含む論理パスの論理コンポーネントがworkdirに対応していることをどのようにして知ることができますか？ リアルパスがcwdと一致するまで、一度に1つのコンポーネントを取得することでそれを実行できる可能性がありますが、それはハッキーでエラーが発生しやすいと感じます。 このように見える最初のシンボリックリンクを信頼するのは危険だと感じます。 また、この方法で解決するまで、遭遇するすべての絶対パスでrealpath（）を実行する必要があります。

ビルドシステムジェネレータは、ビルドステートメントおよびbuild.ninjaのコマンドラインで絶対パスを生成するときに使用したworkdirへの論理パスを正確に認識しています。 したがって、これはworkdirパスの最も信頼できる情報源です。 この情報を忍者に伝える方法が必要なだけなので、私が提案したninja_workdirバインディングです。

わかりません、ごめんなさい。 私の検出ロジックが機能しない例を挙げていただけますか？

ビルドシステムジェネレーターがビルドツリーの内側（ビルドツリーの別の場所または全体の外側を指す）にシンボリックリンクを配置すると、破損する可能性があります。

getcwd（）： /var/xyz/build
depfileエントリ： /home/foo/build/subdir-link/bar.h
realpath（depfileエントリ）： /var/xyz/build/subdir-real/bar.h
相対リアルパス： subdir-real/bar.h
depfileエントリからそれを削除します：???

CMakeはこれを行いませんが、一般的にビルドシステムジェネレーターはこれを行うことができます。

それがサポートされていないと言っても、検出は次のように直面する可能性があります。

getcwd（）： /var/xyz/build
1000個のdepfileエントリ： /home/foo/ext-lib/bar{1,2,...}.h
1000 realpath（depfileエントリ）： /var/xyz/ext-lib/bar{1,2,...}.h
1000の相対リアルパス：cwdの下になし

ここで、それが1000のソースのdepfileに表示され、ヒットが発生しないことを想像してください。 これは、このヒューリスティックに一致しない100万のrealpath（）呼び出しです。 そして、それはソースが再構築され、そのdepfileが再解析されるたびに繰り返されます。

ビルドツリー内のシンボリックリンク->はい、それを実際にサポートすることはできません。とにかく、他のあらゆる種類の問題が発生します（至る所で実際にパスする必要はありません）。

2番目の例はかなり人工的に聞こえます。 通常、depfileは、システムヘッダーではなく、ローカル依存関係で始まります。

それが本当にパフォーマンスの問題であることが判明した場合、workdirを.ninja_depsにキャッシュできますか？

ソース外のビルドでは、ビルドツリーを指すdepfileエントリはほとんどありません。 これは非常に一般的です：

getcwd（）： /var/xyz/build
1000個のdepfileエントリ：/ home / foo / project-source / bar {1,2、...}。h
1000 realpath（depfileエントリ）：/ var / xyz / project-source / bar {1,2、...}。h
1000の相対リアルパス：cwdの下になし

Ninjaは、万が一の場合に備えて、これらすべてに対してrealpath()を呼び出すか、実際のシステムコールを回避するために何らかの結果のテーブルを維持する必要があります。 cwdに解決されるシンボリックリンクパスにいつ遭遇するかを事前に知ることはできず、それが見つかるかどうかさえわかりません。

depfileで絶対パスと現実パスを混在させることが現在機能していないことを考えると、それがどのように「非常に一般的」であるかわかりませんか？

私の例の形式のdepfileは、シンボリックリンクや混合パスを使用していない場合でも、すでに非常に一般的です。 ほとんどのビルドツリーにそれらがあります。 忍者はヒューリスティックが必要かどうかを事前に知ることができないため、万が一の場合に備えてrealpath()システムコールをブロックする必要があります。

多分私はあなたの例を誤解しました。 3000エントリの1つのdepfileを意味しますか、それともそれぞれ1000エントリのdepfileの3つの別々の例でしたか？

つまり、1000個のdepfileエントリが任意の数のdepfileに分散しているということです。 それは1つである可能性があります。 それはたくさんあるかもしれません。 プロジェクト全体で10000のエントリが存在する可能性があります。 それらのパスはファイルシステム上の任意の場所を指すことができ、実際にビルドツリーを指す場合とそうでない場合があります。

パスがこのように混在する結果とCMakeLists.txtの例を挙げてください（1000である必要はなく、それぞれ1つだけです）。

現在、CMakeはほとんどの場合、パスの混合を回避するように注意しているため、 CMakeLists.txtファイルに表示するのは困難です。 ただし、CMakeの課題追跡システムには、忍者が最初にこれを修正しないと修正できない問題に関する問題があります。 たとえば、 CMake Issue13894を参照してください。 ユーザーは、ビルドツリー内のソース（およびおそらくディレクトリを含む）に対しても、またはソース内ビルドを実行する場合でも、コンパイラへの絶対パスを指定できることを望んでいます。 これは、CMakeのMakefileジェネレーターで正常に機能します。 Ninjaでこれを行うと、depfileは絶対パスで返され、 build.ninjaの相対パスと一致しません。 たぶん、すべての絶対パスに切り替えることができますが、ここで上で説明したように、そうする必要はありません。

おそらく、これをテストに試すことができますhttps://github.com/ClausKlein/build-performance/commit/8013836486e3a459474eb374f6c3da5e20983443

ここに示されている問題は、 https： //github.com/ninja-build/ninja/issues/1251#issue-210080507に基づいています。
それはあなたが望むだけ多くのターゲットを生成します。 つまり、それぞれ2つのソースファイルを持つ2つのサブデューア：

PWD=/Users/clausklein/Workspace/build-performance/build

rule cp
  command = cp $in $out

rule cc
  depfile = $out.d
  deps = gcc
  command = gcc -c -I$PWD $IN -o $out $FLAGS -MMD -MT $out -MF $out.d

rule link
  command = gcc -o $out $in $LINK_PATH $LINK_LIBRARIES

build foo: phony foo.h
build foo.h: cp foo.h.in

build bin/main0.o: cc /Users/clausklein/Workspace/build-performance/build/subdir0/main.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir0/main.c
build /Users/clausklein/Workspace/build-performance/build/subdir0/file0.o: cc /Users/clausklein/Workspace/build-performance/build/subdir0/file0.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir0/file0.c

build bin/main1.o: cc /Users/clausklein/Workspace/build-performance/build/subdir1/main.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir1/main.c
build /Users/clausklein/Workspace/build-performance/build/subdir1/file0.o: cc /Users/clausklein/Workspace/build-performance/build/subdir1/file0.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir1/file0.c

build bin/main0: link bin/main0.o /Users/clausklein/Workspace/build-performance/build/subdir0/file0.o 
build bin/main1: link bin/main1.o /Users/clausklein/Workspace/build-performance/build/subdir1/file0.o 

build all: phony foo bin/main0 bin/main1 
default all

これは、CMakeのMakefileジェネレーターで正常に機能します。

Makeはシンボリックリンクの問題をどのように処理しますか？

Makeはシンボリックリンクの問題をどのように処理しますか？

Makefileジェネレーターは現在depfileを使用しておらず、独自の近似スキャンを実行します。 これは、MakefileジェネレーターにC ++ 20モジュールのサポートを追加する一環として更新される可能性があります。その時点で、depfileパスの解釈は、ここで提案されているものと同様に調整する必要があります。

1つのオプションは、今のところninja_workdirをスキップし、少なくともgetcwd()が最上位であると想定して、混合パスを調整するようにNinjaに教えることです。 そうすれば、少なくとも混合パスは、一般的なシンボリックリンクなしの場合に機能します。 次に、 ninja_workdirを追加して、後でより複雑なケースをサポートできます。

誰かがこれを修正してください。 これでとてもイライラします。

私はCMakeとVSCodeでARM-GCCを使用しています。 ソース内ビルドを使用すると、パスは（ルートディレクトリではなく）「ビルド」ディレクトリに相対的であるため、VSCodeはパスを解決できなくなります。つまり、クリックするだけでは不十分です。代わりに、コマンドラインウィンドウのパスを自分で検索する必要があります。 CMakeのツリー外ビルドを使用すると、Eclipseの「IntelliSense」が壊れ、CMakeサブプロジェクトで問題が発生します。 今のところ私の解決策は、デフォルトで絶対パスを使用するため、MakeFilesを使用することです。 ただし、Ninjaの方が優れており、読みやすいファイル（rules.ninja ...）が生成され、コマンドラインでのビルド出力も優れています。 Makeには、マルチスレッドコンテキストでコマンドラインに警告を出力する際に​​問題があります。つまり、複数の警告がインターリーブされます。 これにより、シングルスレッドを構築することになりますが、これも非常に面倒です。

誰かがこれを修正してください。 これでとてもイライラします。

私はCMakeとVSCodeでARM-GCCを使用しています。 ソース内ビルドを使用する場合、パスは「ビルド」ディレクトリからの相対パスです...

回避策があります：ソースツリーの外側のビルドディレクトリを選択してください！ つまり、_ $ TMPDIR /..._

ClausKleinに感謝しますが、回避策はソースビルドから外れていますが、他のスクリプトによって参照されているため、ツリー内のファイルが必要です。 また、これは非標準のビルド要件です。

今のところ私の解決策は、CMakeを常に絶対パスを使用するように変更することです。 なぜこれの選択肢がないのか分かりません。 ただし、他の誰かがこれを必要とする場合は、CMakev3.18.1のパッチを次に示します。

@@ -241,7 +241,7 @@ void cmNinjaTargetGenerator::AddIncludeFlags(std::string& languageFlags,
   // Add include directory flags.
   std::string includeFlags = this->LocalGenerator->GetIncludeFlags(
     includes, this->GeneratorTarget, language,
-    language == "RC", // full include paths for RC needed by cmcldeps
+    true, // full include paths for RC needed by cmcldeps
     false, config);
   if (this->GetGlobalGenerator()->IsGCCOnWindows()) {
     std::replace(includeFlags.begin(), includeFlags.end(), '\\', '/');
@@ -1133,8 +1133,7 @@ void cmNinjaTargetGenerator::WriteObjectBuildStatement(
   const std::string& fileConfig, bool firstForConfig)
 {
   std::string const language = source->GetLanguage();
-  std::string const sourceFileName =
-    language == "RC" ? source->GetFullPath() : this->GetSourceFilePath(source);
+  std::string const sourceFileName = source->GetFullPath();
   std::string const objectDir = this->ConvertToNinjaPath(
     cmStrCat(this->GeneratorTarget->GetSupportDirectory(),
              this->GetGlobalGenerator()->ConfigDirectory(config)));

注意、cmakeのパッチがありましたが、 https：//github.com/ninja-build/ninja/issues/1251を参照してください。

忍者のパッチが必要です！

最後のコメントで、相対パスの代わりに絶対パスを使用するCMakeのパッチを示しました。 これは、NinjaとのカスタムCMakeヘッダーの依存関係を壊すため（たとえば、生成されたヘッダーファイルは.jsonファイルに依存しているため）、悪い考えであることがわかります。 この問題はここでのこの問題に由来すると思いますが、私は愚かすぎて理解できませんでした。

誰かがそれに興味を持っているなら、私は今、相対パスで忍者を使用しています。 統合端末内の相対パスをクリックできるように、VSCodeの拡張機能を作成しました。 拡大

@GrandChris素晴らしい！ Outputタブでも機能させるチャンスはありますか？

@weliveindetail https://github.com/GrandChris/TerminalRelativePath/issuesで新しい問題を自由に作成し、ユースケースを詳細に説明してください。 ただし、VSCodeの[出力]タブの動作は統合端末とは異なり、この点で動作を拡張するAPIはないと思います。

よろしくお願いします。 最終的には、クリック可能な相対パスは、おそらくVSCodeまたはCMake拡張機能で解決されるはずです。 彼らの側でpingを実行します。

参考までに、これはCMake Issue21865で再び取り上げられました。 これは、depfileで検出された依存関係にbuild.ninjaとまったく同じパス表現を使用させるのが簡単ではない（可能ですか？）場合の別の例です。

1917は、それ自体で役立つ機能として、上記で提案されたninja_workdirバインディングを追加します。 それがマージされたら、この問題の修正をフォローアップできます。

@jhasseこれをアップストリームで修正するための許容可能なソリューションを考え出したいです。 ninja_workdirは問題を解決します。 私は上記の私のケースを主張しました。 他にどのような代替案を提案しますか？

ご指摘のとおり、問題（depfile絶対パスとマニフェスト相対パスの混合は再構築を中断します）は仕様によるものです。 ディスカッションでいくつかの問題に触れたので（ビルドディレクトリのシンボリックリンクなど）、より具体的な問題を作成する必要があると思います。

最初のコメントの2つのユースケースの場合、私の代替案は次のようになります。

これにより、IDEがエラーメッセージと一致し、元のファイルを参照するためのより良い出力が生成されます。

IDEを修正するか、 /FCまたは-fabs-path-diagnosticsをコンパイラに渡します。

また、デバッグ情報に記録されるパスに影響を与える可能性があります。

これもコンパイラで修正する必要があります。 -fdebug-prefix-mapを確認することをお勧めしますが、問題が正確に何であるかはわかりません。

この問題を示すスクリプトは次のとおりです：ninja-bug.bash.txt

実際には、それは忍者の現在の振る舞いを示しています。 2つの問題

1. 「私のIDEはコンパイラの出力を正しいファイルに一致させることができません」
2. 「デバッグ情報に絶対パスが必要です」

さらに説明が必要です。 そうでなければ、これは私にはXY問題のように見えます（Xは「絶対パスと相対パスの混合」であり、Yは1または2のいずれかです）。

私は、解決策が「他のすべてのツールでこれを回避する」ことであるべきではないと本当に思います。

1924は、 ninja_workdirアプローチに基づいた、テストによる完全に機能する修正を示しています。 これを使用するジェネレーターは、上記のすべての問題を解決できます。

私も、それらを回避策とは見なしていないためです。

これはGNUgccオプションではありません！

Am 05.03.2021 um 16:58 schrieb Jan Niklas [email protected] ：

IDEを修正するか、/ FChttps ：//docs.microsoft.com/de-de/cpp/build/reference/fc-full-path-of-source-code-file-in-diagnosticsまたは-fabs-を渡しますコンパイラへのpath-diagnosticshttps ：//reviews.llvm.org/D23816 。

また、デバッグ情報に記録されるパスに影響を与える可能性があります。

この問題を示すスクリプトは次のとおりです：ninja-bug.bash.txt

実際には、それは忍者の現在の振る舞いを示しています。

あなたが引用した私の投稿は、これが現在文書化されている動作であることを認めています。
この問題の目的は、設計を問題にすることです。
役立たないユースケースのクラスを示します。

2つの問題...（1）...（2）...さらに説明が必要です。

これらは、によって解決が容易になる問題の2つの例にすぎません。
絶対パスをツールに渡します。 絶対パスは不合理ではありません
そのような特定のインスタンスで他のソリューションが利用可能であるという理由だけで
問題（一部のベンダーから入手可能なツールの特定の機能を使用）。
絶対パスは、更新なしでこれらの問題の大規模なクラスを解決するのに役立ちます
生態系の残りの部分に。 以前に投稿したように：

相対パスと絶対パスのメリットについては、永遠に議論することができます。 忍者はすべき
それについては意見がありません。 ここでの問題は、次のような場合の調整です。
両方とも単一のビルド内で使用されます。 ビルドシステムジェネレータは常に
ツールがパスで何をするかを制御します。

複雑な実世界のビルドシステムでは、任意の数のレイヤーが存在する可能性があります
スクリプト、ラッパー、ツールなど（あらゆる種類のベンダーから）の
ビルドファイルジェネレータによってbuild.ninjaで書き込まれたパスと実際のパス
depfileで忍者が遭遇しました。 特定のファイルを参照できる場合があります
build.ninjaからのパスが直接与えられていないツールからのdepfile。
depfilesがNinjaの現在の設計で機能するために、ツール全体
スタックは、 build.ninjaジェネレーターがどのように表現するかを正確に伝える必要があります
ビルドステートメントのこれらのパス、およびそれらを保持または変換する機能があります
同じようにそれら。 これは一般的に扱いにくいです。

忍者は小さなデザイン変更でこの問題を解決することができます：
build.ninjaに相対パスを含むdepfileの絶対パス（およびその逆）
逆）。 同じファイルへの任意のパスを調整するように求めているのではなく、
depfileの/path/to/some/fileはのsome/fileと同じであることを認識してください
ビルドファイル/path/to/build.ninja 。

そのような設計更新の前例があります。 忍者が最初に始まったとき、希望
パスは常にまったく同じでninjaが遭遇するということでした
ビルドファイルジェネレータが書き込んだバイト単位の表現
build.ninja 。 git blame -M -C -w -- src/util.ccを実行し、履歴を確認します
CanonicalizePathの
デザイン哲学はリラックスしなければなりませんでした。 これはそのような場合の別のクラスです。

物事は私が同意しないということです

忍者はそれについて意見を述べるべきではありません。

そもそも。

これは一般的に扱いにくいです。

では、具体的な問題は何ですか？ 少し混乱してすみません。

そもそも「Ninjaはそれについて意見を述べるべきではない」という意見には賛成できません…では、具体的な問題は何ですか？

これは特定の問題に関するものではなく、絶対パスを使用して解決するのがはるかに簡単な問題のクラス全体に関するものです。 開発者がツールに絶対パスを渡したい理由は関係ありません。特定のケースに当てはまる理由が何であれ、絶対パスを使用したいだけです。 ビルドシステムは、ポリシーを指示するためではなく、ユーザーにサービスを提供するために存在します。 Ninjaはビルドシステムのアセンブリ言語であると想定されていますが、混合スタイルのパスを使用してビルドシステムを表現する方法はありません。

Ninjaのアップストリーム変更のポリシーでは、問題を効率を損なうことなく解決できる場合は、Ninjaアップストリームではなく、ビルドファイルジェネレーターで問題を解決する必要があります。 この場合、ビルドファイルジェネレータからのdepfileパスの汎用ninja_workdirスタイルの調整を提供する唯一の方法は、depfileを生成するすべてのコマンドの後に、一致するようにdepfile内のパスを修正する追加のコマンドを挿入することです。忍者がロードする前のビルドファイル。 その追加のコマンドには、＃1924よりもはるかに高い独自のランタイムコストがあります（ ninjaプロセス内の少数の追加のメモリ内ルックアップ）。 したがって、汎用の調整は、上流の忍者で提供する方が効率的であり、含める候補です。

絶対パスと相対パスを混在させるのではなく、すべてに絶対パスを使用する場合でも、人間工学上の厄介な問題があります。 ユーザーがninjaに、偽のターゲットではなく特定の出力ファイル（たとえば、 ninja out/my_executableやninja out/foo/bar.o ）を再生成するように要求した場合、絶対パスまたは忍者を渡すことを忘れないでください。紛らわしい「不明なターゲット」エラーで失敗します。 逆の問題も存在します。build.ninjaファイルが相対パスを使用している場合、ユーザーはninjaに絶対パスを再構築するように要求する可能性があります。

私が管理しているNinjaジェネレーターツールの1つでは、すべてのbuildステートメントに相対パスとそれに対応する絶対パスの両方を出力として含めることでこれを回避しています。 それは機能しますが、忍者の制限を回避するのは本当にハックのように感じます。 （編集：また、build.ninjaが相対パスのみを使用し、別の絶対パスに移動した後も機能する場合は、絶対パスエイリアスを追加するとその機能が損なわれます。）

確かに、これはdepfilesとまったく同じ問題ではありませんが、Ninjaは一般的に絶対パスと相対パスの同等性をよりよく認識している必要があることを示唆しています。

@comexありがとう、それは有効な懸念です。 そのための新しい問題を開くことができますか？

開発者がツールに絶対パスを渡したい理由は関係ありません[...]

同意しません。

この場合、depfileパスの汎用ninja_workdirスタイルの調整を提供する唯一の方法[...]

そもそもなぜninja_workdirスタイルの調整が必要なのですか？

そもそもなぜninja_workdirスタイルの調整が必要なのですか？

これにより、開発者は、制御しないツールによってdepfileで生成された絶対パスを処理しながら、 build.ninjaで相対パスを使用できます。 そうしないと、忍者の設計上の制限と組み合わせてそのようなツールに対応するために、 build.ninjaで絶対パスを使用することを余儀なくされる可能性があります。 私の提案は、相対パスの使用を妨げるものではありません。 それはそれらのより多くの使用を可能にします。

＃1924と同じ調整を実装するために＃1925を開きましたが、 ninja_workdirバインディングはありません。 これにより、depfileパスを調整するという決定と、シンボリックリンクを使用して論理workdirパスをサポートするという決定が分離されます。

[...]制御しないツールによってdepfilesに生成される絶対パス。

そのようなツールの例はありますか？

世界中のすべての人が使用するすべてのツールの動作を予測することはできません。 私たちが制御するツールについても、絶対パスで簡単に解決できる上記のいくつかのケースについてはすでに説明しましたが、相対パスで解決するにはツール固有のオプションと細心の注意が必要です。 同様の理由で、CMakeはいくつかのケースで絶対パスを優先します。 他のすべてのジェネレーターが実行しているのに、Ninjaジェネレーターがそれを実行していないというバグレポートがいくつかあります。 依存関係の問題を追跡するのに何時間も費やしましたが、それはビルドマニフェストパスと調整されていないdepfileパスの別のインスタンスであることがわかりました。 ツールは、Ninjaが依存関係をキャプチャするために必要な情報を提供しますが、Ninjaはそれを無視します。

あなたの立場は、相対的な道は普遍的に優れているという意見として出くわします。 他の人々は、場合によっては絶対パスの方が優れているという異なる意見を持っています。 相対的なパスを伝道するためのビルドツールの場所ではないと思います。

私の提案は、忍者に少量のインフラストラクチャを追加します。 何が痛いの？ それを持たないことは、はるかに大きなコストを外部化します。

はい、そうです！

また、絶対パスを使用すると、cmakeは重複するコンパイラインクルードパスを排除できます。
これにより、ビルド時間が再び短縮されます。

午前09.03.2021um 19:20 schrieb Brad [email protected] ：

相対的なパスを伝道するためのビルドツールの場所ではないと思います。

Qtのクイックコンパイラで生成されたcppファイルで直面している問題に関して、CMakeの問題を設定し、ユニティビルドを有効にしました。 私の地元の調査によると、忍者ははるかに高速なビルドシステムですが、この星座では信頼性がありません。 現在、回避策を見つけたり、ビルド時間の増加を正当化する方法の問題に直面しています。

CMakeは、最近までこの忍者の問題によって隠されていた循環依存の問題に遭遇しました。 この問題が修正されていれば、CMakeの問題をもっと早く発見できたでしょう。