En una instalación en inglés, "Nota: incluido el archivo:% s% s \ n" aparece como recurso en la tabla de cadenas en VC \ bin \ 1033 \ clui.dll.

1033 es el identificador de configuración regional para "inglés (Estados Unidos)".

Desafortunadamente, no conozco ninguna opción de línea de comando para forzar cl en la configuración regional 1033. Supongo que si se instalan varias configuraciones regionales, usa la configuración del sistema para determinar cuál usar.

Entonces, supongo que tendríamos que agregar varios idiomas a la búsqueda de prefijos en el analizador / showIncludes. : /

Creo que cmcldeps (el analizador CMake de esta salida) usa una expresión regular, algo así como "[^:] +: [^:] +: (. *)", Para tomar todas las líneas de salida que se parecen a showincludes output. No he examinado el código demasiado porque eventualmente me gustaría implementar algo así y no quiero violar ningún derecho de autor. :)

La parte complicada es no confundir showinclude salida con advertencias. sfcheng, ¿podría pegar la salida china de Visual Studio cl.exe cuando muestra un mensaje de advertencia o error?

Se ve así: no es ascii 58, por lo que podría agregar una arruga. Quizás el número de línea "(\ d +)" que estará en errores podría ser una señal útil.

Desafortunadamente, no conozco ninguna opción de línea de comando para forzar cl en la configuración regional 1033.

Desafortunadamente, no hay una forma (limpia) de hacer esto. Las versiones en idiomas extranjeros de VS tendrían otros recursos de configuración regional en un número diferente (por ejemplo, 1041 para JA).
Lo que aprendimos: siempre instale la versión EN de VS, luego instale el paquete de idioma si es necesario :(

Pero, afortunadamente, "error Cnnnn" y "warning Cnnnn" nunca se localizan. Entonces podemos usarlos como clave. Pero como dijo @sgraham , los números de línea parecen más prometedores porque también permitirían filtrar la salida 'nota:'.

No estoy seguro de si: no son ascii 58. En la versión japonesa, estos son ciertamente ascii 58.

FWIW, la salida japonesa se vería así:

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

Arte relacionado: https://bugzilla.mozilla.org/show_bug.cgi?id=587372 (acérquese allí: lea el prefijo de una var env, realice una comprobación de autoconf para verificar / mostrar Incluye trabajos de análisis. No es genial).

Idea similar al error de mozilla: podría haber una var de nivel superior msvs_includes_prefix , y los generadores podrían escribirla compilando un archivo #include "knownheader.h" ficticio con / showIncludes y escribiendo lo que esté delante de "knownheader.h "en la salida cl.exe en ese nivel superior var. Ninja entonces usaría msvs_includes_prefix como el prefijo / showIncludes.

Mientras CMake se configura, el prefijo de inclusión se lee de una compilación ficticia,
https://github.com/Kitware/CMake/blob/master/Modules/CMakeClDeps.cmake
donde se usa una expresión regular, luego el prefijo se pasa como argumento a la herramienta,
https://github.com/Kitware/CMake/blob/master/Source/cmcldeps.cxx
y std :: string :: substr se usa para procesar la salida cl.exe.

Supongo que ninja también necesita aceptar un argumento adicional (global).
(como sugirió nico)

CMake también usa cmcldeps para generar dependencias para archivos .rc primero "compilando" el archivo .rc con cl que genera el archivo de dependencia, y luego lo procesa con la herramienta rc.
No estoy seguro de si esto podría integrarse en ninja o cómo.

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

¿Funciona esto con prefijos que no son Ascii?

665 se fusiona. Sin embargo, es posible que tengamos que repetir un poco los problemas de codificación, por lo que dejar esto abierto hasta que se verifique que funciona.

Con un local francés, ninja 1.8.2 y CMake 3.10.2, esto todavía sucede ...

665 agregó msvc_deps_prefix. ¿Cmake establece eso? @syntheticpp @mathstuf

@nico Veo código en CMake que lo hace referencia.

Sigue sucediendo en Visual Studio Community 15.9.7 ...

Para que conste, esto todavía me está sucediendo con la siguiente configuración:
CMake 3.14
Ninja 1.8.2 (el que se envía con Visual Studio 2019)
Local francés.

EDITAR: Mejor solución alternativa: configure VSLANG=1033 en el entorno para obligar a CL a generar mensajes en inglés.

Solución alternativa antigua:
Y para aquellos que también tuvieron este problema, mi solución fue comentar la siguiente línea en $CMAKE_PATH\share\cmake-3.14\Modules\Platform\Windows-MSVC.cmake :
#set(CMAKE_NINJA_DEPTYPE_${lang} msvc) (línea 368 en la mía)

Desafortunadamente, esto hace que CMake genere deps = gcc lugar de solo eliminar la línea deps, pero eso no parece romper mis compilaciones. YMMV. Ésta es una solución.

Configurar deps = gcc probablemente sea benigno sin configurar depfile también.

@DrFrankenstein ¿ https://github.com/ninja-build/ninja/pull/1671

¡Lo intentaré esta semana!

Desafortunadamente, eso no lo solucionó.

Construí ninja a partir de esa rama, luego usé esa versión de ninja para construirse a sí mismo nuevamente, y aún así filtró los mensajes de inclusión a la terminal.

Me parece que el problema aquí podría ser con el controlador de inclusión de MSVC.

¿La gramática para eso no reconoce correctamente la salida de cl.exe?

Bien...

Parece que es un problema con el inglés codificado.

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

¿Te apetece jugar con ese prefijo en inglés en la parte superior de la función para ver si te funciona mejor?

¡Decir ah! De hecho, iba a mirar allí mañana. Parece que lo atrapaste antes de que yo tuviera la oportunidad de hacerlo.

Acabo de apagar mi computadora por la noche. ¡Me pondré en contacto con usted mañana!

Sin embargo, vale la pena señalar que deps_prefix debe contener la cadena localizada como se establece en el archivo rules.ninja (generalmente detectada y configurada por CMake). Solo usa el codificado si está ausente.

Sospecho que la lógica justo después de que podría ser el verdadero culpable. Pero como dije, haré una sesión de investigación / depuración adecuada mañana.

Las codificaciones no coinciden. deps_prefix está en Latin-1 (donde el NBSP antes de los dos puntos es 0xA0), y line está en CP437 por alguna razón (NBSP = 0xFF).

Creo que CL mismo está generando CP437, pero el rules.ninja generado por CMake está en Latin-1. Supongo que se produjo alguna conversión en el lado de CMake, pero eso requerirá más investigación.

EDITAR: Parece que CL se generará en la página de códigos de la consola. ( Fuente 1 , Fuente 2 ). No estoy seguro de cómo podemos obligarlo a que sea otra cosa.

Quizás podamos unir los dos convirtiéndolos a una codificación común como UTF-8 (o lo que Ninja prefiera usar), por ejemplo, llamando a MultiByteToWideChar(CP_OEMCP, ...) en la salida CL, y MultiByteToWideChar(1252, ...) en la cadena que proviene de rules.ninja.

Pensando en esto ... esto podría ser culpa de CMake. En Windows, el comando execute_process parece convertir la salida del comando a UTF-8 internamente (y acepta un parámetro ENCODING opcional para especificar la codificación de la salida). Por lo tanto, lo vuelve a escribir en UTF-8 en el archivo rules.ninja (donde NBSP es 0xA0 y no 0xFF).

Intenté cambiar CMAKE_DETERMINE_MSVC_SHOWINCLUDES_PREFIX para usar ENCODING NONE (no realizar conversión), pero parecía romper todo tipo de cosas en CMake.

Entonces, la pregunta que tengo ahora es ... ¿debería el msvc_deps_prefix ninja ser una coincidencia bit a bit de la salida del compilador, o debería estar en la codificación que se espera que tenga el archivo, en cuyo caso sería el de Ninja? trabajo para hacer las conversiones adecuadas de la salida del compilador?

@bradking ¿ Pensamientos sobre la codificación y la detección de prefijos aquí?

Históricamente, ninja ha codificado de forma agnóstica (siempre que la codificación utilice el mismo byte que ASCII para '/'). Sin embargo, Windows podría complicarlo.

CLParser::FilterShowIncludes Ninja está usando memcmp para comparar msvc_deps_prefix con las líneas en la salida de MSVC, por lo que, de hecho, el valor debe ser una coincidencia bit a bit. CMake puede necesitar algo de trabajo para preservar eso. CMake actualmente se convierte a UTF-8 internamente, por lo que quizás todo lo que falta es volver a convertir a la codificación de la página de códigos al escribir el valor en build.ninja .

IIRC, la codificación de salida de MSVC puede verse afectada por variables de entorno y / o banderas. Eso significa que podemos terminar con la salida del compilador en una codificación diferente a la página de códigos en la que Ninja está operando y usando para interpretar cadenas en build.ninja . Tales casos pueden requerir apoyo adicional de Ninja para manejarlos, pero se necesitaría una mayor investigación.

No pude encontrar ninguna variable de entorno que afecte a la página de códigos utilizada por CL. Creo que solo usa la página de códigos asociada con el proceso (que se basa en la configuración regional del sistema o en la configuración de la consola si el proceso se está ejecutando en una).

Sin embargo, existe una variable de entorno que establece el idioma utilizado por CL, VSLANG , que puede ser útil como solución para los usuarios afectados por este error. Configurar VSLANG=1033 antes de generar los archivos ninja evitará que ocurra el error.

Solo para reafirmar mi comentario anterior en diferentes palabras: Ninja trata sus archivos de entrada como bytes (sin codificación) y hace comparaciones de cadenas de bytes ignorantes de codificación, para intentar evadir estos problemas. Necesita que los bytes que aparecen en el archivo build.ninja coincidan con los bytes que lee ninja del proceso stdout, pero a ninja no le importan las codificaciones.

Después de que CMake generara todos los archivos de compilación, convertí manualmente rules.ninja a UTF-8 que contiene una línea msvc_deps_prefix = 注意: 包含文件: , y luego las cosas se arreglaron. (Ese archivo solía estar en codificación GB2312, que corresponde a la página de códigos predeterminada 936). Supongo que se podrían hacer cambios en CMake para que siempre convierta rules.ninja a UTF-8.

No tengo experiencia trabajando en configuraciones regionales que no sean la página de códigos 936 o 65001, por lo que no tengo idea de si la solución anterior es una solución universal.

Mismo problema y se las arregla para borrar esta salida con add / W2 en lugar de / W3 en CMAKE_CXX_FLAGS

Esto está relacionado con el n. ° 1766