英語のインストールでは、「注：ファイルを含む：％s％s \ n」がVC \ bin \ 1033 \ clui.dllの文字列テーブルにリソースとして表示されます。

1033は、「英語（米国）」のロケール識別子です。

残念ながら、clを1033ロケールに強制するコマンドラインオプションを知りません。 複数のロケールがインストールされている場合は、システム設定を使用してどちらを使用するかを決定すると思います。

したがって、/ showIncludesパーサーのプレフィックス検索にさまざまな言語を追加する必要があると思います。 ：/

cmcldeps（この出力のCMakeパーサー）は、「[^：] +：[^：] +：（。*）」のような正規表現を使用して、showincludes出力のように見えるすべての出力行を取得すると思います。 最終的にはそのようなものを実装したいと思っており、著作権を侵害したくないので、コードをあまり詳しく調べていません。 :)

トリッキーな部分は、showincludesの出力と警告を混同しないことです。 sfcheng、警告またはエラーメッセージを表示するときに、Visual Studio cl.exeの中国語の出力を貼り付けることができますか？

のように見えます：ASCII 58ではないので、しわが追加される可能性があります。 エラーになる可能性のある行番号「（\ d +）」は、有用なシグナルである可能性があります。

残念ながら、clを1033ロケールに強制するコマンドラインオプションを知りません。

残念ながら、これを行う（クリーンな）方法はありません。 VSの外国語バージョンには、異なる数の他のロケールリソースがあります（たとえば、JAの場合は1041）。
私たちが学んだこと：常にVSのENバージョンをインストールし、必要に応じて言語パックをインストールします:(

しかし、幸いなことに、「エラーCnnnn」と「警告Cnnnn」はローカライズされません。 したがって、それらをキーとして使用できます。 しかし、 @ sgrahamが言ったように、行番号は 'note：'出力を除外することもできるので、より有望に見えます。

：がアスキー58ではないかどうかはわかりません。日本語版では、これらは確かにアスキー58です。

FWIW、日本語の出力は次のようになります。

C:\cygwin\home\oku>type main.c
#include <stdio.h>
int nah(void){}; /* Trigger "function must return a value */
main(){return nah();}

C:\cygwin\home\oku>cl /showIncludes main.c
Microsoft(R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

main.c
メモ: インクルード ファイル:  C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\stdio.h
メモ: インクルード ファイル:   C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\crtdefs.h
メモ: インクルード ファイル:    C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\sal.h
メモ: インクルード ファイル:     c:\program files (x86)\microsoft visual studio10.0\vc\include\codeanalysis\sourceannotations.h
メモ: インクルード ファイル:    C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\vadefs.h
メモ: インクルード ファイル:   C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\swprintf.inl
c:\cygwin\home\oku\main.c(2) : warning C4716: 'nah' : 値を返さなければいけません

関連アート： https ：//bugzilla.mozilla.org/show_bug.cgi？id = 587372（アプローチ：env varからプレフィックスを読み取り、autoconfチェックを行って/ showIncludesの解析動作を確認します。あまり良くありません。）

mozillaのバグに似たアイデア：トップレベルの変数msvs_includes_prefixが存在する可能性があり、ジェネレーターは/ showIncludesを使用してダミーの#include "knownheader.h"ファイルをコンパイルし、「knownheader.h」の前にあるものを書き込むことでそれを書き込むことができます。そのトップレベル変数へのcl.exe出力の "。 Ninjaは、msvs_includes_prefixを/ showIncludesプレフィックスとして使用します。

CMakeが構成している間、インクルードプレフィックスは1つのダミービルドから読み取られます。
https://github.com/Kitware/CMake/blob/master/Modules/CMakeClDeps.cmake
正規表現が使用されている場合、後でプレフィックスが引数としてツールに渡されます。
https://github.com/Kitware/CMake/blob/master/Source/cmcldeps.cxx
std :: string :: substrは、cl.exe出力の処理に使用されます。

忍者も追加の（グローバルな）議論を受け入れる必要があると思います。
（ニコが提案したように）

CMakeはまた、cmcldepsを使用して、依存関係ファイルを生成するclを使用して.rcファイルを最初に「コンパイル」し、次にrcツールで処理することによって.rcファイルの依存関係を生成します。
これを忍者に統合できるかどうか、またはどのように統合できるかはわかりません。

https://github.com/martine/ninja/pull/665

これは非ASCIIプレフィックスで機能しますか？

665がマージされます。 ただし、エンコーディングの問題についてはまだ少し繰り返す必要があるかもしれないので、これが機能していることが確認されるまでこれを開いたままにしておきます。

フランスの地元の忍者1.8.2とCMake3.10.2でも、これはまだ起こります...

665はmsvc_deps_prefixを追加しました。 cmakeはそれを設定しますか？ @syntheticpp @mathstuf

@nicoCMakeにコードがあります。

Visual Studio Community15.9.7でまだ発生しています...

ちなみに、これは次の構成でまだ発生しています。
CMake 3.14
Ninja 1.8.2（Visual Studio 2019に同梱されているもの）
フランス語のロケール。

編集：より良い回避策： CLに英語メッセージを出力させるように環境にVSLANG=1033を設定します。

古い回避策：
また、この問題にぶつかった人のために、私の回避策は$CMAKE_PATH\share\cmake-3.14\Modules\Platform\Windows-MSVC.cmakeの次の行をコメントアウトすること
#set(CMAKE_NINJA_DEPTYPE_${lang} msvc) （私の368行目）

残念ながら、これによりCMakeはdeps行を削除する代わりにdeps = gccを生成しますが、それは私のビルドを壊すようには見えませんでした。 YMMV。 これは回避策です。

deps = gccを設定しても、 depfileを設定しなくても、おそらく問題はありません。

@DrFrankensteinこのPRを忍者コードベースに適用した後、これを再現してみませんか？ https://github.com/ninja-build/ninja/pull/1671

今週はやってみます！

残念ながら、それはそれを修正しませんでした。

そのブランチから忍者をビルドし、そのバージョンの忍者を使用して再度ビルドしましたが、それでもインクルードメッセージがターミナルにリークされました。

ここでの問題はMSVCインクルードハンドラーにあるように思われます。

そのための文法はcl.exeからの出力を正しく認識していませんか？

上手...

ハードコードされた英語の問題のようです。

https://github.com/ninja-build/ninja/blob/master/src/clparser.cc

string CLParser::FilterShowIncludes(const string& line,
                                    const string& deps_prefix) {
  const string kDepsPrefixEnglish = "Note: including file: ";
  const char* in = line.c_str();
  const char* end = in + line.size();
  const string& prefix = deps_prefix.empty() ? kDepsPrefixEnglish : deps_prefix;
  if (end - in > (int)prefix.size() &&
      memcmp(in, prefix.c_str(), (int)prefix.size()) == 0) {
    in += prefix.size();
    while (*in == ' ')
      ++in;
    return line.substr(in - line.c_str());
  }
  return "";
}

@DrFrankenstein

関数の上部にある英語の接頭辞をいじって、それがもっとうまくいくかどうかを確認したいと思いますか？

ハ！ 私は実際に明日そこを見るつもりでした。 私がチャンスを得る前にあなたがそれを捕まえたようです。

私はちょうど夜のために私のコンピュータをシャットダウンしました。 明日お返事します！

ただし、 deps_prefixは、rules.ninjaファイル（通常はCMakeによって検出および設定されます）で設定されているローカライズされた文字列が含まれている必要があります。 存在しない場合にのみ、ハードコードされたものを使用します。

それが実際の犯人であるかもしれない直後の論理を私は疑う。 しかし、私が言ったように、私は明日適切な調査/デバッグセッションを行います。

エンコーディングが一致しません。 deps_prefixはLatin-1（コロンの前のNBSPは0xA0）であり、 lineは何らかの理由でCP437にあります（NBSP = 0xFF）。

CL自体がCP437を出力していると思いますが、CMakeで生成されたrules.ninjaはLatin-1です。 CMake側で変換が発生したと思いますが、さらに掘り下げる必要があります。

編集：CLはコンソールのコードページが何であれ出力するようです。 （ソース1 、ソース2 ）。 どうすればそれを他のものにすることができるのかわかりません。

おそらく、CL出力でMultiByteToWideChar(CP_OEMCP, ...)を呼び出し、 MultiByteToWideChar(1252, ...)呼び出すなどして、両方をUTF-8（またはNinjaが使用することを好むもの）などの一般的なエンコーディングに変換することで、2つをまとめることができます。 rules.ninjaからの文字列。

これを振り返って...これはCMakeのせいかもしれません。 Windowsでは、 execute_processコマンドはコマンドの出力を内部でUTF-8に変換するようです（出力のエンコーディングを指定するためにオプションのENCODINGパラメーターを受け入れます）。 したがって、それをUTF-8のrules.ninjaファイルに書き戻します（NBSPは0xA0であり、0xFFではありません）。

CMAKE_DETERMINE_MSVC_SHOWINCLUDES_PREFIXをENCODING NONE CMAKE_DETERMINE_MSVC_SHOWINCLUDES_PREFIXを使用するように変更しようとしました（変換を実行しません）が、CMakeのあらゆる種類のものを壊したようです。

だから私が今持っている質問は...忍者のmsvc_deps_prefixがコンパイラの出力のビット単位の一致であるか、それともファイルが期待されるエンコーディングであるか、その場合は忍者のコンパイラ出力から適切な変換を行うための仕事？

@bradkingここでエンコーディングとプレフィックス検出について考えていますか？

歴史的に、忍者はエンコーディングにとらわれませんでした（エンコーディングが '/'にASCIIと同じバイトを使用している限り）。 ただし、Windowsはそれを困難にする可能性があります。

NinjaのCLParser::FilterShowIncludesはmemcmpを使用してmsvc_deps_prefixをMSVCの出力の行と比較しているため、実際に値はビット単位で一致する必要があります。 CMakeはそれを維持するためにいくつかの作業が必要な場合があります。 CMakeは現在内部でUTF-8に変換するため、おそらく不足しているのは、値をbuild.ninjaに書き込むときにコードページのエンコーディングに変換し直すことだけです。

IIRC、MSVCの出力エンコーディングは、環境変数やフラグの影響を受ける可能性があります。 つまり、Ninjaが動作し、 build.ninja文字列を解釈するために使用しているコードページとは異なるエンコーディングでコンパイラ出力が生成される可能性があります。 このような場合は、忍者からの追加のサポートが必要になる場合がありますが、さらに調査する必要があります。

CLが使用するコードページに影響を与える環境変数が見つかりませんでした。 プロセスに関連付けられたコードページ（システムの地域設定、またはプロセスが1つで実行されている場合はコンソール設定に基づく）を使用しているだけだと思います。

ただし、CLで使用される言語VSLANGを設定する環境変数があります。これは、このバグの影響を受けるユーザーの回避策として役立ちます。 忍者ファイルを生成する前にVSLANG=1033設定すると、バグの発生を防ぐことができます。

上記のコメントを別の言葉で言い換えると、Ninjaは入力ファイルを（エンコードなしの）バイトとして扱い、文字列のエンコードに依存しないバイト比較を行って、これらの問題を回避しようとします。 build.ninjaファイルに表示されるバイトは、ninjaがプロセスstdoutから読み取るバイトと一致する必要がありますが、ninjaはエンコードを気にしません。

CMakeがすべてのビルドファイルを生成した後、 rules.ninjaをmsvc_deps_prefix = 注意: 包含文件:行を含むUTF-8に手動で変換したところ、問題が修正されました。 （そのファイルは、デフォルトのコードページ936に対応するGB2312エンコーディングでした。）CMakeに変更を加えて、常にrules.ninjaをUTF-8に変換できると思いますか？

コードページ936または65001以外のロケールでの作業経験はないので、上記の解決策が普遍的な修正であるかどうかはわかりません。

同じ問題があり、CMAKE_CXX_FLAGSで/ W3の代わりに/ W2を追加してこの出力を消去することができます

これは＃1766に関連しています