영어 설치에서 "참고 : 파일 포함 : % s % sn"은 VCbin1033clui.dll의 문자열 테이블에 리소스로 나타납니다.

1033은 "영어 (미국)"에 대한 로케일 식별자입니다.

불행히도 cl을 1033 로케일로 강제하는 명령 줄 옵션을 알지 못합니다. 여러 로케일이 설치된 경우 시스템 설정을 사용하여 사용할 항목을 결정한다고 가정합니다.

따라서 / showIncludes 파서의 접두사 검색에 다양한 언어를 추가해야한다고 생각합니다. : /

cmcldeps (이 출력의 CMake 파서)는 "[^ :] + : [^ :] + : (. *)"와 같은 정규식을 사용하여 showincludes 출력처럼 보이는 모든 출력 행을 가져옵니다. 나는 결국 그런 것을 구현하고 싶고 저작권을 침해하고 싶지 않기 때문에 코드를 너무 세게 보지 않았습니다. :)

까다로운 부분은 혼란스럽지 않습니다. showincludes 출력과 경고가 있습니다. sfcheng, 경고 또는 오류 메시지를 표시 할 때 Visual Studio cl.exe의 중국어 출력을 붙여 넣을 수 있습니까?

그것은 ascii 58이 아니므로 주름이 추가 될 수 있습니다. 오류가있는 줄 번호 "(d +)"가 유용한 신호일 수 있습니다.

불행히도 cl을 1033 로케일로 강제하는 명령 줄 옵션을 알지 못합니다.

안타깝게도이를 수행 할 수있는 (깨끗한) 방법은 없습니다. 외국어 버전의 VS에는 다른 번호 (예 : JA의 경우 1041)의 다른 로캘 리소스가 있습니다.
배운 내용 : 항상 EN 버전의 VS를 설치하고 필요한 경우 언어 팩을 설치합니다.

그러나 다행히 "오류 Cnnnn"및 "경고 Cnnnn"은 현지화되지 않습니다. 그래서 우리는 그것들을 키로 사용할 수 있습니다. 그러나 @sgraham이 말했듯이 줄 번호는 'note :'출력을 필터링 할 수 있기 때문에 더 유망 해 보입니다.

나는 확실하지 않다 : are not ascii 58. 일본어 버전에서 이것들은 확실히 ascii 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

mozilla 버그와 유사한 아이디어 : 최상위 var msvs_includes_prefix 있을 수 있으며 생성자는 / showIncludes로 더미 #include "knownheader.h" 파일을 컴파일하고 "knownheader.h 앞에있는 내용을 작성하여 작성할 수 있습니다. "cl.exe 출력에서 ​​해당 최상위 변수로. Ninja는 msvs_includes_prefix를 / showIncludes 접두사로 사용합니다.

CMake가 구성하는 동안 포함 접두사는 하나의 더미 빌드에서 읽습니다.
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 출력을 처리하는 데 사용됩니다.

ninja는 또한 추가 (전역) 인수를 허용해야한다고 가정합니다.
(니코가 제안한 것처럼)

또한 CMake는 cmcldeps를 사용하여 종속성 파일을 생성하는 cl로 .rc 파일을 먼저 "컴파일"한 다음 rc 도구로 처리하여 .rc 파일에 대한 종속성을 생성합니다.
이것이 닌자에 어떻게 통합 될 수 있는지 확실하지 않습니다.

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

비 Ascii 접두사에서도 작동합니까?

665가 병합됩니다. 그래도 인코딩 문제에 대해 약간 반복해야 할 수도 있으므로 작동이 확인 될 때까지 열어 두어야합니다.

프랑스어 로컬, ninja 1.8.2 및 CMake 3.10.2를 사용하면 여전히 발생합니다.

665는 msvc_deps_prefix를 추가했습니다. cmake가 설정합니까? 트윗 담아 가기

@nico 나는 그것을 참조하는 CMake의 코드를 봅니다.

Visual Studio Community 15.9.7에서 계속 발생 ...

기록을 위해 이것은 다음 구성으로 여전히 나에게 발생합니다.
CMake 3.14
Ninja 1.8.2 (Visual Studio 2019와 함께 제공되는 버전)
프랑스어 로케일.

편집 : 더 나은 해결 방법 : 환경에서 VSLANG=1033 를 설정하여 CL이 영어 메시지를 출력하도록합니다.

이전 해결 방법 :
또한이 문제를 겪은 사람들을 위해 내 해결 방법은 $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 "";
}

안녕하세요.

함수의 상단에있는 영어 접두사를 엉망으로 만들고 싶습니까?

하아! 사실 내일 그곳을 살펴 보려고 했어요. 내가 기회를 갖기 전에 당신이 그것을 잡은 것 같습니다.

밤새 컴퓨터를 종료했습니다. 내일 다시 연락 드리겠습니다!

하지만 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 ). 나는 우리가 그것을 다른 것으로 강제 할 수있는 방법을 잘 모르겠습니다.

아마도 우리는 둘 다 UTF-8 (또는 Ninja가 선호하는 것)과 같은 공통 인코딩으로 변환함으로써 둘을 함께 가져올 수 있습니다. 예를 들어 CL 출력에서 MultiByteToWideChar(CP_OEMCP, ...) 를 호출하고 MultiByteToWideChar(1252, ...) rules.ninja에서 오는 문자열에.

이것에 대해 생각해 보면 ... 이것은 CMake의 잘못 일 수 있습니다. Windows에서 execute_process 명령은 명령의 출력을 내부적으로 UTF-8로 변환하는 것처럼 보입니다 (그리고 출력의 인코딩을 지정하기 위해 선택적 ENCODING 매개 변수를 허용 함). 따라서 rules.ninja 파일에서 UTF-8로 다시 기록합니다 (여기서 NBSP는 0xFF가 아니라 0xA0 임).

나는 변경 시도 CMAKE_DETERMINE_MSVC_SHOWINCLUDES_PREFIX 사용하여 ENCODING NONE (어떤 변환을 수행하지 않습니다)하지만, CMake에서 모든 일을 깰 것 같았다.

그래서 제가 지금 가지고있는 질문은 ... ninja의 msvc_deps_prefix 가 컴파일러의 출력과 비트 단위로 일치해야하는지, 아니면 파일이 예상되는 어떤 인코딩으로되어 있어야하는지,이 경우 Ninja의 것이어야합니다. 컴파일러 출력에서 ​​적절한 변환을 수행하는 작업?

@bradking 여기 인코딩 및 접두사 감지에 대한 생각?

역사적으로 ninja는 인코딩이 불가지론 적이었습니다 (인코딩이 '/'에 ASCII와 동일한 바이트를 사용하는 한). 그러나 Windows는이를 어렵게 만들 수 있습니다.

Ninja의 CLParser::FilterShowIncludes 는 memcmp 를 사용하여 msvc_deps_prefix 를 MSVC 출력의 줄과 비교하므로 실제로 값은 비트 단위 일치 여야합니다. CMake는이를 보존하기 위해 몇 가지 작업이 필요할 수 있습니다. CMake는 현재 내부적으로 UTF-8로 변환하므로 build.ninja 값을 쓸 때 누락 된 것은 코드 페이지의 인코딩으로 다시 변환되는 것입니다.

IIRC, MSVC의 출력 인코딩은 환경 변수 및 / 또는 플래그의 영향을받을 수 있습니다. 즉, Ninja가 작동하고 build.ninja 문자열을 해석하는 데 사용하는 코드 페이지와 다른 인코딩으로 컴파일러 출력으로 끝날 수 있습니다. 이러한 경우 처리를 위해 Ninja의 추가 지원이 필요할 수 있지만 추가 조사가 필요합니다.

CL에서 사용하는 코드 페이지에 영향을 미치는 환경 변수를 찾을 수 없습니다. 나는 프로세스와 관련된 코드 페이지를 사용한다고 생각합니다 (시스템의 지역 설정을 기반으로하거나 프로세스가 하나에서 실행되는 경우 콘솔 설정).

그러나 CL에서 사용하는 언어를 설정하는 환경 변수 VSLANG 이 _is_ 있으며, 이는이 버그의 영향을받는 사용자를위한 해결 방법으로 유용 할 수 있습니다. ninja 파일을 생성하기 전에 VSLANG=1033 를 설정하면 버그가 발생하지 않습니다.

위의 주석을 다른 단어로 다시 말하면 : Ninja는 입력 파일을 (인코딩없는) 바이트로 취급하고 이러한 문제를 피하기 위해 문자열의 인코딩 무지 바이트 비교를 수행합니다. ninja가 프로세스 stdout에서 읽는 바이트와 일치하려면 build.ninja 파일에 나타나는 바이트가 필요하지만 ninja는 인코딩에 대해 신경 쓰지 않습니다.

CMake 모든 빌드 파일을 생성 한 후, 나는 수동으로 변환 rules.ninja UTF-8 선 포함에 msvc_deps_prefix = 注意: 包含文件: , 다음 일들이 고정되었다. (이 파일은 기본 코드 페이지 936에 해당하는 GB2312 인코딩으로되어있었습니다.) CMake가 항상 rules.ninja 를 UTF-8로 변환하도록 변경할 수 있다고 생각합니다.

코드 페이지 936 또는 65001 이외의 로케일에서 작업 한 경험이 없으므로 위의 솔루션이 범용 수정인지 여부는 알 수 없습니다.

동일한 문제이며 CMAKE_CXX_FLAGS에서 / W3 대신 / W2를 추가 하여이 출력을 지우십시오.

이것은 # 1766과 관련이 있습니다.