एक अंग्रेजी इंस्टॉल पर "नोट: फाइल सहित:% s% s \ n" स्ट्रिंग तालिका में संसाधन के रूप में VC \ bin \ 1033 \ clui.dll में प्रकट होता है।

1033 "अंग्रेजी (संयुक्त राज्य अमेरिका)" के लिए स्थानीय पहचानकर्ता है।

मैं दुर्भाग्य से 1033 लोकेल में cl को मजबूर करने के लिए किसी भी कमांड लाइन विकल्प के बारे में नहीं जानता। मुझे लगता है कि यदि कई स्थान स्थापित हैं, तो यह निर्धारित करने के लिए सिस्टम सेटिंग्स का उपयोग करता है कि किसका उपयोग करना है।

इसलिए, मुझे लगता है कि हमें / showIncludes parser में उपसर्ग खोज में विभिन्न भाषाओं को जोड़ना होगा। : /

मुझे लगता है कि cmcldeps (इस आउटपुट का CMake पार्सर) एक regex का उपयोग करता है, जैसे कि "[^:] +: [^:] +: (*। *)", सभी आउटपुट लाइनों को हथियाने के लिए जो showincludes आउटपुट की तरह दिखते हैं। मैंने कोड को बहुत मुश्किल से नहीं देखा है क्योंकि मैं अंततः ऐसा कुछ लागू करना चाहता हूं और मैं किसी भी कॉपीराइट का उल्लंघन नहीं करना चाहता। :)

मुश्किल हिस्सा चेतावनियों को चेतावनी के साथ आउटपुट को भ्रमित नहीं कर रहा है। चेतावनी या त्रुटि संदेश दिखाते समय क्या आप Visual Studio cl.exe का चीनी आउटपुट पेस्ट कर सकते हैं?

ऐसा लगता है कि: ascii 58 नहीं है, ताकि एक शिकन जोड़ सके। शायद लाइन नंबर "(\ d +)" जो त्रुटियों में होगा, उपयोगी संकेत हो सकता है।

मैं दुर्भाग्य से 1033 लोकेल में cl को मजबूर करने के लिए किसी भी कमांड लाइन विकल्प के बारे में नहीं जानता।

दुर्भाग्य से ऐसा करने का कोई (साफ) तरीका नहीं है। वीएस के विदेशी भाषा संस्करणों में अलग-अलग संख्या में अन्य स्थानीय संसाधन होंगे (जैसे जेए के लिए 1041)।
हमने क्या सीखा: हमेशा वीएस का एन संस्करण स्थापित करें, फिर जरूरत पड़ने पर भाषा पैक स्थापित करें :(

लेकिन सौभाग्य से, "त्रुटि Cnnnn" और "चेतावनी Cnnnn" कभी भी स्थानीयकृत नहीं होती है। इसलिए हम उन्हें कुंजी के रूप में उपयोग कर सकते हैं। लेकिन जैसा कि @shamham ने कहा, लाइन नंबर अधिक आशाजनक

मुझे यकीन है कि नहीं या नहीं: 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 (वहां का तरीका: env var से उपसर्ग पढ़ें, सत्यापित करने / दिखाने के लिए ऑटोकैफ़ की जाँच करें) पार्स कार्यों को शामिल नहीं करना महान है।)

मोजिला बग के समान आइडिया: इसमें एक टॉपवेल var msvs_includes_prefix हो सकता है, और जनरेटर यह लिख सकते हैं कि डमी #include "knownheader.h" फ़ाइल / showIncludes के साथ और जो कुछ भी हो, उसे "knowheader.h" के सामने लिखें। "उस toplevel var में cl.exe आउटपुट में। निंजा तब msvs_includes_prefix / showIncludes उपसर्ग के रूप में उपयोग करेगा।

जबकि CMake कॉन्फ़िगर करता है, शामिल उपसर्ग एक डमी बिल्ड से पढ़ा जाता है,
https://github.com/Kitware/CMake/blob/master/Modules/CMakeClDeps.s.seake
जहाँ एक regex का उपयोग किया जाता है, बाद में उपसर्ग पर उपकरण के तर्क के रूप में पारित किया जाता है,
https://github.com/Kitware/CMake/blob/master/Source/cmcldeps.cxx
और std :: string :: root का उपयोग cl.exe आउटपुट को प्रोसेस करने के लिए किया जाता है।

मुझे लगता है कि निंजा को भी एक अतिरिक्त (वैश्विक) तर्क को स्वीकार करने की आवश्यकता है।
(जैसा nico सुझाव दिया गया है)

CMake भी पहले। संकलन के लिए .rc फ़ाइलों के लिए निर्भरताएँ उत्पन्न करने के लिए cmcldeps का उपयोग करता है। CL फ़ाइल, जो निर्भरता फ़ाइल जनरेट करता है, और उसके बाद इसे rc टूल के साथ संसाधित करता है।
यकीन नहीं होता है या यह निंजा में कैसे एकीकृत किया जा सकता है।

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

क्या यह गैर-असिसी उपसर्गों के साथ काम करता है?

665 का विलय हो गया है। हमें एन्कोडिंग मुद्दों पर थोड़ा फिर भी चलना पड़ सकता है, इसलिए जब तक यह सत्यापित न हो जाए, तब तक इसे खुला छोड़ दें।

एक फ्रेंच लोकल, निंजा 1.8.2 और CMake 3.10.2 के साथ, यह अभी भी होता है ...

665 ने msvc_deps_prefix जोड़ा। क्या cmake वह सेट करता है? @syntheticpp @mathstuf

@ निको मैं में कोड देखता हूं जो इसे संदर्भित करता है।

अभी भी विजुअल स्टूडियो कम्युनिटी पर हो रहा है 15.9.7 ...

रिकॉर्ड के लिए, यह मेरे लिए अभी भी निम्न कॉन्फ़िगरेशन के साथ हो रहा है:
सीएमके 3.14
निंजा 1.8.2 (विजुअल स्टूडियो 2019 के साथ एक जहाज)
फ्रेंच लोकेल।

संपादित करें: बेहतर वर्कअराउंड: सीएल को अंग्रेजी संदेशों को आउटपुट करने के लिए मजबूर करने के लिए VSLANG=1033 वातावरण में सेट करें ।

पुराना वर्कअराउंड:
और उन लोगों के लिए भी जिन्होंने इस मुद्दे को मारा, मेरा काम $CMAKE_PATH\share\cmake-3.14\Modules\Platform\Windows-MSVC.cmake में निम्नलिखित पंक्ति पर टिप्पणी करना था:
#set(CMAKE_NINJA_DEPTYPE_${lang} msvc) (मेरा में लाइन 368)

यह दुर्भाग्य से सीएमके द्वारा डिप्स लाइन को हटाने के बजाय deps = gcc उत्पन्न करने का कारण बनता है, लेकिन यह मेरे बिल्ड को तोड़ने के लिए नहीं लगता है। YMMV। यह एक वर्कअराउंड है।

deps = gcc सेट करना शायद depfile सेट किए बिना सौम्य है।

@DrFrankenstein क्या आप इस कोड को निनजा कोडबेस में लागू करने के बाद इसे पुन: प्रस्तुत करने की कोशिश करने के लिए तैयार होंगे? https://github.com/ninja-build/ninja/pull/1671

मैं इसे इस हफ्ते एक शॉट दूँगा!

दुर्भाग्य से, यह तय नहीं किया।

मैंने उस शाखा से निंजा का निर्माण किया, फिर निंजा के उस संस्करण का इस्तेमाल खुद को फिर से बनाने के लिए किया, और यह अभी भी टर्मिनल में शामिल संदेशों को लीक कर दिया।

मुझे ऐसा लगता है कि यहाँ मुद्दा MSVC के साथ हैंडलर शामिल हो सकता है।

क्या इसके लिए व्याकरण क्ली। एफ से आउटपुट को सही तरीके से नहीं पहचान रहा है?

कुंआ...

ऐसा लगता है कि यह हार्डकोड अंग्रेजी के साथ एक समस्या है।

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 को स्थानीय स्ट्रिंग होना चाहिए जैसा कि नियमों में सेट किया गया है। निन्जा फ़ाइल (आमतौर पर सीएमके द्वारा पता लगाया और सेट किया गया है)। यह अनुपस्थित होने पर केवल हार्ड-कोडेड का उपयोग करता है।

मुझे तर्क पर संदेह है कि यह वास्तविक अपराधी हो सकता है। लेकिन जैसा कि मैंने कहा, मैं कल एक उचित जांच / डिबगिंग सत्र करूंगा।

एनकोडिंग मेल नहीं खाते। deps_prefix लैटिन -1 में है (जहां कॉलन से पहले NBSP 0xA0 है), और line किसी कारण से CP437 में है (NBSP = 0xFF)।

मुझे लगता है कि सीएल खुद CP437 का उत्पादन कर रहा है, लेकिन CMake- जनरेटेड नियम। Ninja लैटिन -1 में है। मैं अनुमान लगा रहा हूं कि सीएमके पक्ष में कुछ रूपांतरण हुआ है, लेकिन इसके लिए अधिक खुदाई की आवश्यकता होगी।

संपादित करें: ऐसा लगता है कि कंसोल के कोडपेज में सीएल आउटपुट होगा। ( स्रोत 1 , स्रोत 2 )। मुझे यकीन नहीं है कि हम इसे कुछ और होने के लिए मजबूर कर सकते हैं।

शायद हम दोनों को एक साथ एक आम एन्कोडिंग में परिवर्तित करके दोनों को एक साथ ला सकते हैं जैसे UTF-8 (या जो भी निंजा उपयोग करना पसंद करते हैं), जैसे कि CL आउटपुट पर MultiByteToWideChar(CP_OEMCP, ...) कॉल करके, और MultiByteToWideChar(1252, ...) नियमों से आता है कि स्ट्रिंग पर।

इस पर वापस सोचना ... यह सीएमके दोष हो सकता है। विंडोज पर, execute_process कमांड कमांड के आउटपुट को UTF-8 में आंतरिक रूप से परिवर्तित करने के लिए लगता है (और आउटपुट एन्कोडिंग को निर्दिष्ट करने के लिए वैकल्पिक ENCODING पैरामीटर को स्वीकार करता है)। इस प्रकार यह UTF-8 में नियमों में वापस लिखता है। निन्जा फ़ाइल (जहाँ NBSP 0xA0 है न कि 0xFF)।

मैंने CMAKE_DETERMINE_MSVC_SHOWINCLUDES_PREFIX ENCODING NONE (कोई रूपांतरण नहीं करें) का उपयोग करने की कोशिश की, लेकिन यह CMake में सभी प्रकार की चीजों को तोड़ने के लिए लग रहा था।

तो सवाल मैं अब कर रहा हूँ ... निंजा के msvc_deps_prefix को संकलक के आउटपुट का एक बिटवाइज़ मैच होना चाहिए, या यह होना चाहिए कि फाइल में जो भी एन्कोडिंग होने की उम्मीद है, उस स्थिति में यह निंजा का होगा संकलक उत्पादन से उचित रूपांतरण करने के लिए काम?

यहाँ एन्कोडिंग और उपसर्ग का पता लगाने पर @bradking विचार?

ऐतिहासिक रूप से निन्जा को अज्ञेय (जब तक एन्कोडिंग '' / 'के लिए ASCII के रूप में उपयोग किया जाता है) को एन्कोडिंग किया गया है। हालाँकि, Windows यह मुश्किल बना सकता है।

निंजा के CLParser::FilterShowIncludes उपयोग कर रहा है memcmp तुलना करने के लिए msvc_deps_prefix मूल्य जरूरतों MSVC के उत्पादन में लाइनों के लिए तो वास्तव में एक बिटवाइज़ मैच होने के लिए। सीएमके को इसे संरक्षित करने के लिए कुछ काम की आवश्यकता हो सकती है। CMake वर्तमान में UTF-8 में आंतरिक रूप से परिवर्तित हो जाता है, इसलिए शायद जो सब गायब है वह build.ninja का मान लिखते समय कोडपेज के एन्कोडिंग में वापस परिवर्तित हो रहा है।

IIRC, MSVC का आउटपुट एन्कोडिंग पर्यावरण चर और / या झंडे से प्रभावित हो सकता है। इसका मतलब है कि हम संकलक की तुलना में एक अलग एन्कोडिंग में संकलक आउटपुट के साथ समाप्त हो सकते हैं जिसमें निंजा build.ninja में स्ट्रिंग्स की व्याख्या करने के लिए काम कर रहा है और उपयोग कर रहा है। ऐसे मामलों को संभालने के लिए निंजा से अतिरिक्त सहायता की आवश्यकता हो सकती है लेकिन आगे की जांच की आवश्यकता होगी।

मुझे सीएल द्वारा उपयोग किए गए कोडपेज को प्रभावित करने वाला कोई भी पर्यावरण चर नहीं मिला। मुझे लगता है कि यह प्रक्रिया से जुड़े कोडपेज का उपयोग करता है (जो सिस्टम की क्षेत्रीय सेटिंग्स पर आधारित है, या यदि प्रक्रिया एक में चल रही है तो कंसोल सेटिंग्स द्वारा)।

हालाँकि, _is_ एक पर्यावरण चर है जो CL, VSLANG द्वारा उपयोग की जाने वाली भाषा को सेट करता है, जो इस बग से प्रभावित उपयोगकर्ताओं के लिए एक समाधान के रूप में उपयोगी हो सकता है। निंजा फ़ाइलों को बनाने से पहले VSLANG=1033 सेट करने से बग को होने से रोका जा सकेगा।

बस अलग-अलग शब्दों में मेरी उपरोक्त टिप्पणी को आराम देने के लिए: निंजा इन मुद्दों से बचने की कोशिश करने के लिए अपने इनपुट फाइलों को (एन्कोडिंगलेस) बाइट्स के रूप में मानता है, और एन्कोडिंग-अज्ञानी बाइट की तुलना करता है। आपको बाइट्स की आवश्यकता होती है जो बिल्ड.ninja फ़ाइल में दिखाई देते हैं। बाइट्स को मिलान करने के लिए निंजा प्रक्रिया स्टैडआउट से पढ़ता है, लेकिन निंजा एनकोडिंग की परवाह नहीं करता है।

CMake सभी बिल्ड फ़ाइलों को बनाने के बाद, मैंने मैन्युअल रूप से rules.ninja को UTF-8 में बदल दिया, जिसमें एक लाइन msvc_deps_prefix = 注意: 包含文件: , और फिर चीजें तय हो गईं। (वह फ़ाइल GB2312 एन्कोडिंग में हुआ करती थी, जो डिफ़ॉल्ट कोड पेज 936 के अनुरूप है।) मुझे लगता है कि सीएमके में बदलाव किए जा सकते हैं ताकि यह हमेशा rules.ninja UTF-8 में परिवर्तित हो जाए?

मुझे कोड पेज 936 या 65001 के अलावा अन्य स्थानों पर काम करने का कोई अनुभव नहीं है, इसलिए मुझे कोई पता नहीं है कि क्या उपरोक्त समाधान एक सार्वभौमिक समाधान है, हालांकि।

समान समस्या और CMAKE_CXX_FLAGS में / W3 के बजाय add / W2 के साथ इस आउटपुट को मिटाने का प्रबंधन करें

यह # 1766 से संबंधित है