Sur une installation en anglais "Remarque: fichier inclus:% s% s \ n" apparaît comme ressource dans la table de chaînes dans VC \ bin \ 1033 \ clui.dll.

1033 est l'identificateur de paramètres régionaux pour "Anglais (États-Unis)".

Je ne connais malheureusement aucune option de ligne de commande pour forcer cl dans les paramètres régionaux 1033. Je suppose que si plusieurs paramètres régionaux sont installés, ils utilisent les paramètres système pour déterminer lesquels utiliser.

Donc, je suppose que nous devrons ajouter plusieurs langues à la recherche de préfixe dans l'analyseur / showIncludes. : /

Je pense que cmcldeps (l'analyseur CMake de cette sortie) utilise une expression régulière, quelque chose comme "[^:] +: [^:] +: (. *)", Pour saisir toutes les lignes de sortie qui ressemblent à showincludes output. Je n'ai pas trop regardé le code parce que j'aimerais éventuellement implémenter quelque chose comme ça et je ne veux violer aucun droit d'auteur. :)

La partie délicate est de ne pas confondre showincludes sortie avec des avertissements. sfcheng, pourriez-vous coller la sortie chinoise de Visual Studio cl.exe lors de l'affichage d'un message d'avertissement ou d'erreur?

Cela ressemble à ça: n'est pas ascii 58, donc cela pourrait ajouter une ride. Peut-être que le numéro de ligne "(\ d +)" qui sera en erreur pourrait être un signal utile.

Je ne connais malheureusement aucune option de ligne de commande pour forcer cl dans les paramètres régionaux 1033.

Il n'y a malheureusement pas de moyen (propre) de le faire. Les versions en langue étrangère de VS auraient d'autres ressources locales en nombre différent (par exemple 1041 pour JA).
Ce que nous avons appris: installez toujours la version EN de VS, puis installez le pack de langue si nécessaire :(

Mais heureusement, «erreur Cnnnn» et «avertissement Cnnnn» ne sont jamais localisés. Nous pouvons donc les utiliser comme clé. Mais comme @sgraham l'a dit, les numéros de ligne semblent plus prometteurs car ils permettraient également de filtrer la sortie 'note:'.

Je ne sais pas si oui ou non: ne sont pas ascii 58. Dans la version japonaise, ce sont certainement ascii 58.

FWIW, la sortie japonaise ressemblerait à ceci:

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

Art connexe: https://bugzilla.mozilla.org/show_bug.cgi?id=587372 (approchez-vous ici: lisez le préfixe d'un env var, faites une vérification automatique pour vérifier / showInclut des travaux d'analyse. Pas génial.)

Idée similaire au bogue mozilla: il pourrait y avoir un var msvs_includes_prefix , et les générateurs pourraient l'écrire en compilant un fichier factice #include "knownheader.h" avec / showIncludes et en écrivant tout ce qui se trouve devant "knownheader.h "dans la sortie cl.exe dans ce var de niveau supérieur. Ninja utiliserait alors msvs_includes_prefix comme préfixe / showIncludes.

Pendant la configuration de CMake, le préfixe d'inclusion est lu à partir d'une version factice
https://github.com/Kitware/CMake/blob/master/Modules/CMakeClDeps.cmake
où une expression régulière est utilisée, plus tard le préfixe est passé comme argument à l'outil,
https://github.com/Kitware/CMake/blob/master/Source/cmcldeps.cxx
et std :: string :: substr est utilisé pour traiter la sortie cl.exe.

Je suppose que ninja doit également accepter un argument supplémentaire (global).
(comme Nico l'a suggéré)

CMake utilise également cmcldeps pour générer des dépendances pour les fichiers .rc en "compilant" d'abord le fichier .rc avec cl qui génère le fichier de dépendance, puis le traite avec l'outil rc.
Je ne sais pas si ou comment cela pourrait être intégré dans ninja.

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

Cela fonctionne-t-il avec les préfixes non Ascii?

665 est fusionné. Nous pourrions devoir répéter un peu les problèmes d'encodage, alors laissez cela ouvert jusqu'à ce que cela fonctionne.

Avec un local français, ninja 1.8.2 et CMake 3.10.2, cela arrive encore ...

665 a ajouté msvc_deps_prefix. Est-ce que cmake a réglé cela? @syntheticpp @mathstuf

@nico Je vois du code dans CMake qui y fait référence.

Toujours en cours sur Visual Studio Community 15.9.7 ...

Pour mémoire, cela m'arrive toujours avec la configuration suivante:
CMake 3.14
Ninja 1.8.2 (celui fourni avec Visual Studio 2019)
Langue française.

EDIT: Meilleure solution de contournement: définissez VSLANG=1033 dans l'environnement pour forcer CL à afficher des messages en anglais.

Ancienne solution de contournement:
Et pour ceux qui ont également rencontré ce problème, ma solution de contournement était de commenter la ligne suivante dans $CMAKE_PATH\share\cmake-3.14\Modules\Platform\Windows-MSVC.cmake :
#set(CMAKE_NINJA_DEPTYPE_${lang} msvc) (ligne 368 de la mienne)

Cela amène malheureusement CMake à générer deps = gcc au lieu de simplement supprimer la ligne deps, mais cela n'a pas semblé casser mes constructions. YMMV. Ceci est une solution de contournement.

La configuration de deps = gcc est probablement bénigne sans la configuration de depfile également.

@DrFrankenstein Seriez-vous prêt à essayer de reproduire ceci après avoir appliqué ce PR à la base de code ninja? https://github.com/ninja-build/ninja/pull/1671

Je vais essayer cette semaine!

Malheureusement, cela n'a pas résolu le problème.

J'ai construit ninja à partir de cette branche, puis j'ai utilisé cette version de ninja pour se reconstruire, et les messages d'inclusion ont toujours été divulgués au terminal.

Il me semble que le problème ici pourrait être lié au gestionnaire d'inclusion MSVC.

La grammaire pour cela ne reconnaît-elle pas correctement la sortie de cl.exe?

Bien...

Il semble que ce soit un problème avec l'anglais codé en dur.

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

Avez-vous envie de jouer avec ce préfixe anglais en haut de la fonction pour voir si cela vous convient mieux?

Ha! J'allais en fait chercher là-dedans demain. On dirait que vous l'avez attrapé avant que j'en ai eu la chance.

Je viens d'éteindre mon ordinateur pour la nuit. Je vous recontacterai demain!

Il convient de noter, cependant, que deps_prefix doit contenir la chaîne localisée telle que définie dans le fichier rules.ninja (généralement détectée et définie par CMake). Il utilise uniquement celui codé en dur s'il est absent.

Je soupçonne que la logique juste après cela pourrait être le véritable coupable. Mais comme je l'ai dit, je ferai une session d'enquête / débogage appropriée demain.

Les encodages ne correspondent pas. deps_prefix est en Latin-1 (où le NBSP avant les deux-points est 0xA0), et line est en CP437 pour une raison quelconque (NBSP = 0xFF).

Je pense que CL lui-même produit CP437, mais le rules.ninja généré par CMake est en Latin-1. Je suppose qu'une conversion s'est produite du côté de CMake, mais cela nécessitera plus de recherches.

EDIT: Il semble que CL sortira dans la page de codes de la console. ( Source 1 , Source 2 ). Je ne sais pas comment nous pouvons le forcer à être autre chose.

Peut-être pouvons-nous réunir les deux en les convertissant tous les deux en un encodage commun tel que UTF-8 (ou ce que Ninja préfère utiliser), par exemple en appelant MultiByteToWideChar(CP_OEMCP, ...) sur la sortie CL, et MultiByteToWideChar(1252, ...) sur la chaîne qui provient de rules.ninja.

En y repensant ... cela pourrait être la faute de CMake. Sous Windows, la commande execute_process semble convertir la sortie de la commande en UTF-8 en interne (et accepte un paramètre optionnel ENCODING pour spécifier l'encodage de la sortie). Il le réécrit donc en UTF-8 dans le fichier rules.ninja (où NBSP vaut 0xA0 et non 0xFF).

J'ai essayé de changer CMAKE_DETERMINE_MSVC_SHOWINCLUDES_PREFIX pour utiliser ENCODING NONE (n'effectuer aucune conversion), mais cela semblait casser toutes sortes de choses dans CMake.

Donc, la question que je me pose maintenant est ... est-ce que le msvc_deps_prefix ninja doit être une correspondance au niveau du bit de la sortie du compilateur, ou devrait-il être dans le codage prévu pour le fichier, auquel cas il serait travail pour faire les conversions appropriées à partir de la sortie du compilateur?

@bradking Réflexions sur l'encodage et la détection des préfixes ici?

Historiquement, ninja a codé de manière agnostique (tant que le codage utilisait le même octet que ASCII pour «/»). Cependant, Windows peut rendre cela difficile.

Le CLParser::FilterShowIncludes Ninja utilise memcmp pour comparer msvc_deps_prefix aux lignes dans la sortie de MSVC donc en effet la valeur doit être une correspondance au niveau du bit. CMake peut avoir besoin de quelques travaux pour préserver cela. CMake se convertit actuellement en UTF-8 en interne, donc peut-être que tout ce qui manque est de reconvertir le codage de la page de codes lors de l'écriture de la valeur dans build.ninja .

IIRC, l'encodage de sortie de MSVC peut être affecté par des variables d'environnement et / ou des indicateurs. Cela signifie que nous pouvons nous retrouver avec la sortie du compilateur dans un encodage différent de celui de la page de codes dans laquelle Ninja fonctionne et utilise pour interpréter les chaînes dans build.ninja . De tels cas peuvent nécessiter un soutien supplémentaire de Ninja, mais une enquête plus approfondie serait nécessaire.

Je n'ai trouvé aucune variable d'environnement affectant la page de codes utilisée par CL. Je pense qu'il utilise simplement la page de code associée au processus (qui est basée sur les paramètres régionaux du système, ou par les paramètres de la console si le processus s'exécute dans un).

Cependant, il existe une variable d'environnement qui définit le langage utilisé par CL, VSLANG , ce qui peut être utile comme solution de contournement pour les utilisateurs affectés par ce bogue. Définir VSLANG=1033 avant de générer les fichiers ninja empêchera le bogue de se produire.

Juste pour reformuler mon commentaire ci-dessus en des mots différents: Ninja traite ses fichiers d'entrée comme des octets (sans codage) et fait des comparaisons d'octets ignorant l'encodage des chaînes, pour tenter d'éviter ces problèmes. Vous avez besoin que les octets qui apparaissent dans le fichier build.ninja correspondent aux octets que ninja lit à partir du processus stdout, mais ninja ne se soucie pas des encodages.

Après que CMake ait généré tous les fichiers de construction, j'ai converti manuellement rules.ninja en UTF-8 qui contient une ligne msvc_deps_prefix = 注意: 包含文件: , puis les choses ont été corrigées. (Ce fichier était auparavant en encodage GB2312, qui correspond à la page de codes par défaut 936.) Je suppose que des modifications pourraient être apportées à CMake afin qu'il convertisse toujours rules.ninja en UTF-8?

Je n'ai aucune expérience de travail sur des paramètres régionaux autres que la page de codes 936 ou 65001, donc je n'ai aucune idée si la solution ci-dessus est une solution universelle.

Même problème et parvenez à effacer cette sortie avec add / W2 au lieu de / W3 dans CMAKE_CXX_FLAGS

Ceci est lié à # 1766