Bei einer englischen Installation wird "Hinweis: einschließlich Datei:% s% s \ n" als Ressource in der Zeichenfolgentabelle in VC \ bin \ 1033 \ clui.dll angezeigt.

1033 ist die Gebietsschema-ID für "Englisch (USA)".

Mir ist leider keine Befehlszeilenoption bekannt, mit der cl in das Gebietsschema 1033 gezwungen werden soll. Ich gehe davon aus, dass bei der Installation mehrerer Gebietsschemas die Systemeinstellungen verwendet werden, um zu bestimmen, welche verwendet werden sollen.

Ich denke, wir müssten der Präfixsuche im Parser / showIncludes verschiedene Sprachen hinzufügen. : /

Ich denke, cmcldeps (der CMake-Parser dieser Ausgabe) verwendet einen regulären Ausdruck, etwa "[^:] +: [^:] +: (. *)", Um alle Ausgabezeilen zu erfassen, die wie showincludes-Ausgabe aussehen. Ich habe mir den Code nicht allzu genau angesehen, weil ich irgendwann so etwas implementieren möchte und keine Urheberrechte verletzen möchte. :) :)

Der knifflige Teil ist nicht zu verwechseln. Showincludes-Ausgabe mit Warnungen. sfcheng, könnten Sie die chinesische Ausgabe von Visual Studio cl.exe einfügen, wenn eine Warnung oder eine Fehlermeldung angezeigt wird?

Es sieht so aus: ist nicht ASCII 58, so dass eine Falte hinzufügen könnte. Möglicherweise könnte die fehlerhafte Zeilennummer "(\ d +)" ein nützliches Signal sein.

Mir ist leider keine Befehlszeilenoption bekannt, mit der cl in das Gebietsschema 1033 gezwungen werden soll.

Leider gibt es dafür keinen (sauberen) Weg. Fremdsprachige Versionen von VS hätten andere Gebietsschemaressourcen in anderer Anzahl (z. B. 1041 für JA).
Was wir gelernt haben: Installieren Sie immer die EN-Version von VS und dann bei Bedarf das Sprachpaket :(

Glücklicherweise werden "Fehler Cnnnn" und "Warnung Cnnnn" nie lokalisiert. Wir können sie also als Schlüssel verwenden. Aber wie @sgraham sagte, sehen Zeilennummern vielversprechender aus, da sie auch das Herausfiltern der Ausgabe von 'note:' ermöglichen würden.

Ich bin nicht sicher, ob: nicht ASCII 58 sind. In der japanischen Version sind dies sicherlich ASCII 58.

FWIW, die japanische Ausgabe würde folgendermaßen aussehen:

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' : 値を返さなければいけません

Verwandte Artikel: https://bugzilla.mozilla.org/show_bug.cgi?id=587372 (Ansatz dort: Präfix aus einer env-Variable lesen, Autoconf-Überprüfung durchführen, um zu überprüfen / showIncludes-Parsing-Funktionen. Nicht großartig.)

Idee ähnlich dem Mozilla-Bug: Es könnte eine Toplevel-Variable msvs_includes_prefix , und Generatoren könnten diese schreiben, indem sie eine Dummy-Datei #include "knownheader.h" mit / showIncludes kompilieren und alles schreiben, was vor "unknownheader.h" steht "in der cl.exe-Ausgabe in diese oberste Ebene var. Ninja würde dann msvs_includes_prefix als Präfix / showIncludes verwenden.

Während der CMake-Konfiguration wird das Include-Präfix aus einem Dummy-Build gelesen.
https://github.com/Kitware/CMake/blob/master/Modules/CMakeClDeps.cmake
Wenn ein regulärer Ausdruck verwendet wird, wird das Präfix später als Argument an das Tool übergeben.
https://github.com/Kitware/CMake/blob/master/Source/cmcldeps.cxx
und std :: string :: substr wird zur Verarbeitung der Ausgabe von cl.exe verwendet.

Ich gehe davon aus, dass Ninja auch ein zusätzliches (globales) Argument akzeptieren muss.
(wie von nico vorgeschlagen)

CMake verwendet auch cmcldeps, um Abhängigkeiten für RC-Dateien zu generieren, indem zuerst die RC-Datei mit cl "kompiliert" wird, wodurch die Abhängigkeitsdatei generiert wird, und dann mit dem RC-Tool verarbeitet wird.
Ich bin mir nicht sicher, ob oder wie dies in Ninja integriert werden könnte.

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

Funktioniert dies mit Nicht-Ascii-Präfixen?

665 wird zusammengeführt. Möglicherweise müssen wir die Codierungsprobleme noch ein wenig wiederholen, also lassen Sie dies offen, bis überprüft wird, ob dies funktioniert.

Mit einem französischen Einheimischen, Ninja 1.8.2 und CMake 3.10.2, passiert dies immer noch ...

665 msvc_deps_prefix hinzugefügt. Setzt cmake das? @syntheticpp @mathstuf

@nico Ich sehe Code in CMake, der darauf verweist.

Immer noch in Visual Studio Community 15.9.7 ...

Für die Aufzeichnung passiert mir dies immer noch mit der folgenden Konfiguration:
CMake 3.14
Ninja 1.8.2 (das mit Visual Studio 2019 gelieferte)
Französisches Gebietsschema.

BEARBEITEN: Bessere Problemumgehung: Setzen Sie VSLANG=1033 in der Umgebung, um CL zu zwingen, englische Nachrichten auszugeben.

Alte Problemumgehung:
Und für diejenigen, die ebenfalls auf dieses Problem gestoßen sind, bestand meine Problemumgehung darin, die folgende Zeile in $CMAKE_PATH\share\cmake-3.14\Modules\Platform\Windows-MSVC.cmake zu kommentieren:
#set(CMAKE_NINJA_DEPTYPE_${lang} msvc) (Zeile 368 in meiner)

Dies führt leider dazu, dass CMake deps = gcc generiert, anstatt die deps-Zeile zu entfernen, aber das scheint meine Builds nicht zu beschädigen. YMMV. Dies ist eine Problemumgehung.

Das Setzen von deps = gcc ist wahrscheinlich harmlos, ohne auch depfile zu setzen.

@DrFrankenstein Würdest du versuchen, dies zu reproduzieren, nachdem du diese PR auf die Ninja-Codebasis https://github.com/ninja-build/ninja/pull/1671

Ich werde es diese Woche versuchen!

Leider konnte das nicht behoben werden.

Ich habe Ninja aus diesem Zweig erstellt und dann diese Version von Ninja verwendet, um sich selbst erneut zu erstellen, und es sind immer noch die Include-Nachrichten an das Terminal durchgesickert.

Es scheint mir, dass das Problem hier mit dem MSVC Include Handler sein könnte.

Erkennt die Grammatik dafür die Ausgabe von cl.exe nicht richtig?

Gut...

Es sieht so aus, als wäre es ein Problem mit fest codiertem Englisch.

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

Haben Sie Lust, mit dem englischen Präfix oben in der Funktion herumzuspielen, um zu sehen, ob es Ihnen besser geht?

Ha! Ich würde eigentlich morgen dort reinschauen. Scheint, als hättest du es gefangen, bevor ich die Gelegenheit dazu hatte.

Ich habe gerade meinen Computer für die Nacht heruntergefahren. Ich melde mich morgen bei dir!

Es ist jedoch erwähnenswert, dass deps_prefix die lokalisierte Zeichenfolge enthalten sollte, die in der Datei rules.ninja festgelegt ist (normalerweise von CMake erkannt und festgelegt). Es wird nur das fest codierte verwendet, wenn es nicht vorhanden ist.

Ich vermute, dass die Logik kurz nachdem sie der eigentliche Schuldige sein könnte. Aber wie gesagt, ich werde morgen eine ordnungsgemäße Untersuchung / Debugging-Sitzung durchführen.

Die Codierungen stimmen nicht überein. deps_prefix ist in Latin-1 (wobei der NBSP vor den Doppelpunkten 0xA0 ist) und line ist aus irgendeinem Grund in CP437 (NBSP = 0xFF).

Ich denke, dass CL selbst CP437 ausgibt, aber die CMake-generierten rules.ninja ist in Latin-1. Ich vermute, dass einige Konvertierungen auf der CMake-Seite stattgefunden haben, aber das erfordert mehr Graben.

BEARBEITEN: Es scheint, als würde CL auf jeder Codepage der Konsole ausgegeben. ( Quelle 1 , Quelle 2 ). Ich bin mir nicht sicher, wie wir es zwingen können, etwas anderes zu sein.

Vielleicht können wir die beiden zusammenbringen, indem wir beide in eine gemeinsame Codierung wie UTF-8 konvertieren (oder was auch immer Ninja bevorzugt), z. B. indem wir MultiByteToWideChar(CP_OEMCP, ...) in der CL-Ausgabe und MultiByteToWideChar(1252, ...) aufrufen auf der Zeichenfolge, die von rules.ninja kommt.

Wenn ich daran zurückdenke ... könnte dies CMakes Schuld sein. Unter Windows scheint der Befehl execute_process die Ausgabe des Befehls intern in UTF-8 zu konvertieren (und akzeptiert einen optionalen Parameter ENCODING , um die Codierung der Ausgabe anzugeben). Es schreibt es daher in UTF-8 in die Datei rules.ninja zurück (wobei NBSP 0xA0 und nicht 0xFF ist).

Ich habe versucht, CMAKE_DETERMINE_MSVC_SHOWINCLUDES_PREFIX zu ändern, dass ENCODING NONE (keine Konvertierung durchführen), aber es schien alle möglichen Dinge in CMake zu beschädigen.

Die Frage, die ich jetzt habe, ist ... sollte Ninjas msvc_deps_prefix eine bitweise Übereinstimmung mit der Ausgabe des Compilers sein, oder sollte es in der erwarteten Codierung der Datei sein, in welchem ​​Fall es Ninjas wäre Job, um die richtigen Konvertierungen von der Compiler-Ausgabe zu machen?

@bradking Gedanken zur Kodierung und

Historisch gesehen hat Ninja Agnostiker codiert (solange die Codierung dasselbe Byte wie ASCII für '/' verwendet). Windows könnte dies jedoch schwierig machen.

Ninjas CLParser::FilterShowIncludes verwendet memcmp , um msvc_deps_prefix mit Zeilen in der MSVC-Ausgabe zu vergleichen, sodass der Wert tatsächlich bitweise übereinstimmen muss. CMake benötigt möglicherweise einige Arbeiten, um dies zu bewahren. CMake konvertiert derzeit intern zu UTF-8, sodass möglicherweise nur die Konvertierung in die Codierung der Codepage fehlt, wenn der Wert in build.ninja .

IIRC, die Ausgabecodierung von MSVC kann durch Umgebungsvariablen und / oder Flags beeinflusst werden. Das bedeutet, dass die Compilerausgabe möglicherweise eine andere Codierung aufweist als die Codepage, auf der Ninja arbeitet und zur Interpretation von Zeichenfolgen in build.ninja . Solche Fälle erfordern möglicherweise zusätzliche Unterstützung von Ninja, aber weitere Untersuchungen wären erforderlich.

Ich konnte keine Umgebungsvariable finden, die sich auf die von CL verwendete Codepage auswirkt. Ich denke, es wird nur die mit dem Prozess verknüpfte Codepage verwendet (die auf den regionalen Einstellungen des Systems oder auf den Konsoleneinstellungen basiert, wenn der Prozess in einer ausgeführt wird).

Es gibt jedoch eine Umgebungsvariable, die die von CL verwendete Sprache VSLANG festlegt. Dies kann als Problemumgehung für Benutzer hilfreich sein, die von diesem Fehler betroffen sind. Das Festlegen von VSLANG=1033 vor dem Generieren der Ninja-Dateien verhindert, dass der Fehler auftritt.

Um meinen obigen Kommentar mit anderen Worten zu wiederholen: Ninja behandelt seine Eingabedateien als (codierungslose) Bytes und führt codierungsunabhängige Byte-Vergleiche von Zeichenfolgen durch, um zu versuchen, diese Probleme zu umgehen. Sie benötigen die Bytes, die in der Datei build.ninja angezeigt werden, um mit den Bytes übereinzustimmen, die Ninja aus dem Prozess stdout liest, aber Ninja kümmert sich nicht um Codierungen.

Nachdem CMake alle Build-Dateien generiert hatte, konvertierte ich rules.ninja manuell in UTF-8, das eine Zeile msvc_deps_prefix = 注意: 包含文件: , und dann wurden die Probleme behoben. (Diese Datei hatte früher die GB2312-Codierung, die der Standardcodepage 936 entspricht.) Ich denke, Änderungen könnten an CMake vorgenommen werden, sodass immer rules.ninja in UTF-8 konvertiert wird.

Ich habe keine Erfahrung mit anderen Gebietsschemas als Codepage 936 oder 65001, daher habe ich keine Ahnung, ob die obige Lösung eine universelle Lösung ist.

Gleiches Problem und es gelingt, diese Ausgabe mit add / W2 anstelle von / W3 in CMAKE_CXX_FLAGS zu löschen

Dies hängt mit # 1766 zusammen