Pada penginstalan bahasa Inggris "Catatan: termasuk file:% s% s \ n" muncul sebagai sumber daya dalam tabel string di VC \ bin \ 1033 \ clui.dll.

1033 adalah pengenal lokal untuk "Inggris (Amerika Serikat)".

Saya tidak mengetahui adanya opsi baris perintah untuk memaksa cl ke 1033 lokal sayangnya. Saya berasumsi jika beberapa lokal diinstal, ia menggunakan pengaturan sistem untuk menentukan mana yang akan digunakan.

Jadi, saya kira kita harus menambahkan berbagai bahasa ke pencarian awalan di parser / showIncludes. : /

Saya pikir cmcldeps (pengurai CMake dari keluaran ini) menggunakan regex, seperti "[^:] +: [^:] +: (. *)", Untuk mengambil semua baris keluaran yang terlihat seperti keluaran showincludes. Saya belum melihat kode terlalu keras karena pada akhirnya saya ingin menerapkan sesuatu seperti itu dan saya tidak ingin melanggar hak cipta apa pun. :)

Bagian rumitnya adalah tidak membingungkan output showincludes dengan peringatan. sfcheng, dapatkah Anda menempelkan keluaran bahasa Mandarin dari Visual Studio cl.exe ketika menampilkan peringatan atau pesan kesalahan?

Ini terlihat seperti itu: bukan ascii 58, jadi itu bisa menambah kerutan. Mungkin nomor baris "(\ d +)" yang salah bisa menjadi sinyal yang berguna.

Saya tidak mengetahui adanya opsi baris perintah untuk memaksa cl ke 1033 lokal sayangnya.

Sayangnya, tidak ada cara (bersih) untuk melakukan ini. Versi bahasa asing dari VS akan memiliki sumber lokal lain dalam jumlah yang berbeda (misalnya 1041 untuk JA).
Apa yang kita pelajari: selalu instal VS versi EN, lalu instal paket bahasa jika diperlukan :(

Namun untungnya, "kesalahan Cnnnn" dan "peringatan Cnnnn" tidak pernah dilokalkan. Jadi kita bisa menggunakannya sebagai kuncinya. Tapi seperti yang dikatakan @sgraham , nomor baris sepertinya lebih menjanjikan karena juga memungkinkan penyaringan output 'note:'.

Saya tidak yakin apakah: bukan ascii 58. Dalam versi Jepang, ini pasti ascii 58.

FWIW, keluaran Jepang akan terlihat seperti ini:

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

Seni terkait: https://bugzilla.mozilla.org/show_bug.cgi?id=587372 (pendekatan di sana: baca awalan dari env var, lakukan pemeriksaan autoconf untuk memverifikasi / showIncludes parsing berfungsi. Tidak bagus.)

Ide yang mirip dengan bug mozilla: Mungkin ada var tingkat atas msvs_includes_prefix , dan generator dapat menulisnya dengan menyusun file dummy #include "knownheader.h" dengan / showIncludes dan menulis apa pun yang ada di depan "knownheader.h "dalam keluaran cl.exe ke dalam var tingkat atas itu. Ninja kemudian akan menggunakan msvs_includes_prefix sebagai awalan / showIncludes.

Sementara konfigurasi CMake, awalan include dibaca dari satu build tiruan,
https://github.com/Kitware/CMake/blob/master/Modules/CMakeClDeps.cmake
di mana regex digunakan, kemudian awalan diteruskan sebagai argumen ke alat,
https://github.com/Kitware/CMake/blob/master/Source/cmcldeps.cxx
dan std :: string :: substr digunakan untuk memproses keluaran cl.exe.

Saya berasumsi ninja juga perlu menerima argumen tambahan (global).
(seperti yang disarankan nico)

CMake juga menggunakan cmcldeps untuk menghasilkan dependensi untuk file .rc dengan terlebih dahulu "mengompilasi" file .rc dengan cl yang menghasilkan file dependensi, dan kemudian memprosesnya dengan alat rc.
Tidak yakin apakah atau bagaimana ini bisa diintegrasikan ke dalam ninja.

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

Apakah ini berfungsi dengan awalan non-Ascii?

665 digabungkan. Kami mungkin masih harus mengulang masalah encoding sedikit, jadi biarkan ini terbuka sampai ini diverifikasi berfungsi.

Dengan bahasa Prancis lokal, ninja 1.8.2 dan CMake 3.10.2, ini masih terjadi ...

665 menambahkan msvc_deps_prefix. Apakah cmake mengatur itu? @indomiliter @indomiliter

@ nico Saya melihat kode di CMake yang mereferensikannya.

Masih terjadi di Visual Studio Community 15.9.7 ...

Sebagai catatan, hal ini masih terjadi pada saya dengan konfigurasi berikut:
CMake 3.14
Ninja 1.8.2 (yang dikirimkan dengan Visual Studio 2019)
Lokal Prancis.

EDIT: Solusi yang lebih baik: setel VSLANG=1033 di lingkungan untuk memaksa CL menampilkan pesan bahasa Inggris.

Solusi lama:
Dan bagi mereka yang juga mengalami masalah ini, solusi saya adalah mengomentari baris berikut di $CMAKE_PATH\share\cmake-3.14\Modules\Platform\Windows-MSVC.cmake :
#set(CMAKE_NINJA_DEPTYPE_${lang} msvc) (baris 368 di baris saya)

Sayangnya ini menyebabkan CMake menghasilkan deps = gcc alih-alih hanya menghapus baris deps, tetapi itu sepertinya tidak merusak bangunan saya. YMMV. Ini adalah solusi.

Menyetel deps = gcc mungkin tidak berbahaya tanpa menyetel depfile juga.

@DrFrankenstein Maukah Anda mencoba mereproduksi ini setelah menerapkan PR ini ke basis kode ninja? https://github.com/ninja-build/ninja/pull/1671

Saya akan mencobanya minggu ini!

Sayangnya, itu tidak memperbaikinya.

Saya membangun ninja dari cabang itu, lalu menggunakan versi ninja itu untuk membangun dirinya lagi, dan masih membocorkan pesan penyertaan ke terminal.

Sepertinya saya seperti masalah di sini mungkin dengan penanganan termasuk MSVC.

Apakah tata bahasa untuk itu tidak mengenali keluaran dari cl.exe dengan benar?

Baik...

Sepertinya ini masalah dengan bahasa Inggris hardcode.

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 "";
}

@Tokopedia

Apakah Anda ingin mengotak-atik awalan bahasa Inggris di bagian atas fungsi untuk melihat apakah ada yang lebih baik?

Ha! Saya sebenarnya akan mencari di sana besok. Sepertinya Anda menangkapnya sebelum saya sempat.

Saya baru saja mematikan komputer saya untuk malam ini. Saya akan menghubungi Anda kembali besok!

Perlu dicatat, meskipun, deps_prefix harus berisi string yang dilokalkan seperti yang ditetapkan dalam file rules.ninja (biasanya terdeteksi dan disetel oleh CMake). Ini hanya menggunakan hard-code jika tidak ada.

Saya menduga logika setelah itu mungkin pelakunya yang sebenarnya. Tapi seperti yang saya katakan, saya akan melakukan sesi investigasi / debugging yang tepat besok.

Pengodean tidak cocok. deps_prefix dalam bahasa Latin-1 (NBSP sebelum titik dua adalah 0xA0), dan line dalam CP437 untuk beberapa alasan (NBSP = 0xFF).

Menurut saya CL sendiri mengeluarkan CP437, tetapi rules.ninja yang dibuat CMake menggunakan bahasa Latin-1. Saya menduga bahwa beberapa konversi terjadi di sisi CMake, tetapi itu akan membutuhkan lebih banyak penggalian.

EDIT: Sepertinya CL akan menampilkan codepage konsol apa pun. ( Sumber 1 , Sumber 2 ). Saya tidak yakin bagaimana kita bisa memaksanya menjadi sesuatu yang lain.

Mungkin kita dapat menyatukan keduanya dengan mengonversikan keduanya menjadi pengkodean umum seperti UTF-8 (atau apa pun yang lebih disukai Ninja untuk digunakan), misalnya dengan memanggil MultiByteToWideChar(CP_OEMCP, ...) pada keluaran CL, dan MultiByteToWideChar(1252, ...) pada string yang berasal dari rules.ninja.

Memikirkan kembali ini ... ini mungkin salah CMake. Pada Windows, perintah execute_process tampaknya mengubah keluaran perintah menjadi UTF-8 secara internal (dan menerima parameter opsional ENCODING untuk menentukan pengkodean keluaran). Karena itu, ia menulisnya kembali di UTF-8 di file rules.ninja (di mana NBSP adalah 0xA0 dan bukan 0xFF).

Saya mencoba mengubah CMAKE_DETERMINE_MSVC_SHOWINCLUDES_PREFIX untuk menggunakan ENCODING NONE (tidak melakukan konversi), tetapi tampaknya merusak segala macam hal di CMake.

Jadi pertanyaan yang saya hadapi sekarang adalah ... haruskah ninja msvc_deps_prefix cocok dengan keluaran kompiler, atau haruskah itu dalam pengkodean apa pun yang diharapkan file tersebut, dalam hal ini akan menjadi milik Ninja pekerjaan untuk melakukan konversi yang tepat dari keluaran kompiler?

@bradking Pikiran tentang pengkodean dan deteksi awalan di sini?

Secara historis, ninja telah melakukan pengkodean agnostik (selama pengkodean menggunakan byte yang sama dengan ASCII untuk '/'). Namun, Windows mungkin membuat itu sulit.

Ninja CLParser::FilterShowIncludes menggunakan memcmp untuk membandingkan msvc_deps_prefix dengan baris dalam keluaran MSVC jadi memang nilainya harus cocok dengan bitwise. CMake mungkin perlu bekerja keras untuk mempertahankannya. CMake saat ini mengonversi ke UTF-8 secara internal jadi mungkin semua yang hilang adalah mengonversi kembali ke pengkodean halaman kode saat menulis nilai menjadi build.ninja .

IIRC, pengkodean keluaran MSVC dapat dipengaruhi oleh variabel lingkungan dan / atau tanda. Itu berarti kita mungkin akan mendapatkan keluaran kompilator dalam pengkodean yang berbeda dari halaman kode yang dioperasikan dan digunakan Ninja untuk menafsirkan string di build.ninja . Kasus seperti itu mungkin memerlukan dukungan ekstra dari Ninja untuk ditangani, tetapi penyelidikan lebih lanjut akan diperlukan.

Saya tidak dapat menemukan variabel lingkungan apa pun yang memengaruhi halaman kode yang digunakan oleh CL. Saya pikir itu hanya menggunakan halaman kode yang terkait dengan proses (yang didasarkan pada pengaturan regional sistem, atau dengan pengaturan konsol jika proses berjalan di satu).

Namun, ada _adalah_ variabel lingkungan yang menyetel bahasa yang digunakan oleh CL, VSLANG , yang dapat berguna sebagai solusi bagi pengguna yang terpengaruh oleh bug ini. Menyetel VSLANG=1033 sebelum membuat berkas ninja akan mencegah terjadinya bug.

Hanya untuk menyatakan kembali komentar saya di atas dengan kata-kata yang berbeda: Ninja memperlakukan file inputnya sebagai byte (tanpa pengkodean), dan melakukan perbandingan string encoding-ignorant, untuk mencoba menghindari masalah ini. Anda memerlukan byte yang muncul di file build.ninja agar sesuai dengan byte yang dibaca ninja dari proses stdout, tetapi ninja tidak peduli dengan pengkodean.

Setelah CMake membuat semua file build, saya secara manual mengonversi rules.ninja ke UTF-8 yang berisi baris msvc_deps_prefix = 注意: 包含文件: , dan kemudian semuanya diperbaiki. (File itu dulunya dalam pengkodean GB2312, yang sesuai dengan halaman kode default 936.) Saya kira perubahan dapat dilakukan pada CMake sehingga selalu mengubah rules.ninja menjadi UTF-8?

Saya tidak memiliki pengalaman mengerjakan lokal selain halaman kode 936 atau 65001, jadi saya tidak tahu apakah solusi di atas adalah perbaikan universal.

Masalah yang sama dan berhasil menghapus keluaran ini dengan add / W2 bukannya / W3 di CMAKE_CXX_FLAGS

Ini terkait dengan # 1766