عند التثبيت باللغة الإنجليزية ، يظهر "ملاحظة: تضمين الملف:٪ s٪ s \ n" كمورد في جدول السلسلة في VC \ bin \ 1033 \ clui.dll.

1033 هو معرف الإعدادات المحلية لـ "الإنجليزية (الولايات المتحدة)".

لست على علم بأي خيار سطر أوامر لفرض cl في 1033 لسوء الحظ. أفترض أنه إذا تم تثبيت عدة لغات ، فإنه يستخدم إعدادات النظام لتحديد أيها يجب استخدامه.

لذلك ، أعتقد أنه سيتعين علينا إضافة لغات مختلفة إلى البحث عن البادئة في / showIncludes parser. : /

أعتقد أن cmcldeps (المحلل اللغوي CMake لهذا الإخراج) يستخدم regex ، شيء مثل "[^:] +: [^:] +: (. *)" ، لجلب جميع سطور الإخراج التي تبدو وكأنها تتضمن الإخراج. لم ألقي نظرة على الكود كثيرًا لأنني أرغب في النهاية في تنفيذ شيء من هذا القبيل ولا أريد انتهاك أي حقوق طبع ونشر. :)

الجزء الصعب هو عدم الخلط بين العرض يتضمن الإخراج مع التحذيرات. sfcheng ، هل يمكنك لصق الإخراج الصيني لـ Visual Studio cl.exe عند إظهار رسالة تحذير أو خطأ؟

يبدو أن: ليس ASCII 58 ، بحيث قد يضيف تجعد. ربما يكون رقم السطر "(\ d +)" الذي سيكون به أخطاء قد يكون إشارة مفيدة.

لست على علم بأي خيار سطر أوامر لفرض cl في 1033 لسوء الحظ.

لا توجد طريقة (نظيفة) للقيام بذلك ، للأسف. سيكون لإصدارات اللغات الأجنبية من VS موارد محلية أخرى بأرقام مختلفة (مثل 1041 لـ JA).
ما تعلمناه: قم دائمًا بتثبيت إصدار EN من VS ، ثم قم بتثبيت حزمة اللغة إذا لزم الأمر :(

لكن لحسن الحظ ، لا يتم ترجمة "خطأ Cnnnn" و "تحذير Cnnnn" أبدًا. حتى نتمكن من استخدامها كمفتاح. ولكن كما قال sgraham ، تبدو أرقام الأسطر واعدة أكثر لأنها ستسمح أيضًا بتصفية "ملاحظة:" الإخراج.

لست متأكدًا مما إذا كان: ليس 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 ، لديك فحص تلقائي للتحقق / showIncludes تحليل الأعمال. ليس رائعًا.)

فكرة مشابهة لخطأ الموزيلا: يمكن أن يكون هناك var msvs_includes_prefix toplevel var #include "knownheader.h" مع / showIncludes وكتابة أي شيء أمام "knownheader.h" "في إخراج cl.exe إلى ذلك المستوى var. سيستخدم Ninja بعد ذلك msvs_includes_prefix كبادئة / showIncludes.

أثناء تكوينات CMake ، تتم قراءة بادئة التضمين من بنية وهمية واحدة ،
https://github.com/Kitware/CMake/blob/master/Modules/CMakeClDeps.cmake
حيث يتم استخدام regex ، في وقت لاحق يتم تمرير البادئة كوسيطة للأداة ،
https://github.com/Kitware/CMake/blob/master/Source/cmcldeps.cxx
و std :: string :: substr يُستخدم لمعالجة إخراج cl.exe.

أفترض أن النينجا يحتاج أيضًا إلى قبول حجة (عالمية) إضافية.
(مثل اقترح نيكو)

يستخدم CMake أيضًا cmcldeps لإنشاء تبعيات لملفات .rc من خلال "تجميع" ملف .rc أولاً باستخدام cl الذي ينشئ ملف التبعية ، ثم يقوم بمعالجته باستخدام أداة 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.0 تحديث
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 = gcc بدلاً من مجرد إزالة سطر deps ، لكن هذا لم يكسر تصميماتي. YMMV. هذا حل بديل.

من المحتمل أن يكون تعيين deps = gcc حميدًا بدون تعيين depfile أيضًا.

DrFrankenstein هل أنت مستعد لمحاولة إعادة إنتاج هذا بعد تطبيق العلاقات العامة هذه على قاعدة أكواد النينجا؟ 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 باللاتينية -1 (حيث NBSP قبل النقطتين هو 0xA0) ، و line في CP437 لسبب ما (NBSP = 0xFF).

أعتقد أن CL نفسها تنتج CP437 ، لكن القواعد المولدة من CMake.ninja موجودة في Latin-1. أظن أن بعض التحويل حدث من جانب CMake ، لكن هذا سيتطلب المزيد من الحفر.

تحرير: يبدو أن CL سينتج في أي صفحة كود لوحدة التحكم. ( المصدر 1 ، المصدر 2 ). لست متأكدًا من كيفية إجبارها على أن تكون شيئًا آخر.

ربما يمكننا جمع الاثنين معًا عن طريق تحويلهما إلى ترميز شائع مثل UTF-8 (أو أي شيء يفضل Ninja استخدامه) ، على سبيل المثال عن طريق استدعاء MultiByteToWideChar(CP_OEMCP, ...) عند إخراج CL ، و MultiByteToWideChar(1252, ...) على السلسلة التي تأتي من rules.ninja.

التفكير في هذا ... قد يكون هذا خطأ CMake. في Windows ، يبدو أن الأمر execute_process بتحويل إخراج الأمر إلى UTF-8 داخليًا (ويقبل معلمة ENCODING اختيارية لتحديد ترميز الإخراج). وبالتالي يعيد كتابته في UTF-8 في ملف rules.ninja (حيث يكون NBSP هو 0xA0 وليس 0xFF).

حاولت تغيير CMAKE_DETERMINE_MSVC_SHOWINCLUDES_PREFIX لاستخدام ENCODING NONE (بدون إجراء أي تحويل) ، ولكن يبدو أنه كسر كل أنواع الأشياء في CMake.

لذا فإن السؤال الذي أواجهه الآن هو ... هل يجب أن يكون msvc_deps_prefix الخاص بـ ninja مطابقًا للبت مع إخراج المترجم ، أو يجب أن يكون في أي ترميز متوقع أن يكون الملف ، وفي هذه الحالة سيكون Ninja مهمة للقيام بالتحويلات المناسبة من إخراج المترجم؟

bradking خواطر حول الترميز واكتشاف البادئة هنا؟

من الناحية التاريخية ، كان النينجا يقوم بترميز الحيادية (طالما أن الترميز يستخدم نفس البايت مثل 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 ، والذي يمكن أن يكون مفيدًا كحل بديل للمستخدمين المتأثرين بهذا الخطأ. سيؤدي تعيين VSLANG=1033 قبل إنشاء ملفات النينجا إلى منع حدوث الخطأ.

فقط لإعادة صياغة تعليقي السابق بكلمات مختلفة: تعامل Ninja ملفات الإدخال الخاصة بها على أنها (غير مشفرة) بايت ، وتقوم بإجراء مقارنات بين السلاسل المشفرة والجاهلة ، لمحاولة التهرب من هذه المشكلات. أنت بحاجة إلى وحدات البايت التي تظهر في ملف build.ninja لمطابقة البايتات التي يقرأها النينجا من العملية stdout ، لكن النينجا لا يهتم بالترميزات.

بعد إنشاء CMake لجميع ملفات الإنشاء ، قمت يدويًا بتحويل rules.ninja إلى UTF-8 الذي يحتوي على سطر msvc_deps_prefix = 注意: 包含文件: ، ثم تم إصلاح الأشياء. (اعتاد أن يكون هذا الملف بترميز GB2312 ، والذي يتوافق مع صفحة الشفرة الافتراضية 936.) أعتقد أنه يمكن إجراء تغييرات على CMake بحيث يحول دائمًا rules.ninja إلى UTF-8؟

ليس لدي أي خبرة في العمل على لغات أخرى بخلاف صفحة الرموز 936 أو 65001 ، لذلك ليس لدي أي فكرة عما إذا كان الحل أعلاه إصلاحًا شاملاً أم لا.

نفس المشكلة وتمكن من محو هذا الناتج مع إضافة / W2 بدلاً من / W3 في CMAKE_CXX_FLAGS

هذا مرتبط بـ # 1766