msbuild интерпретирует имена файлов как китайские символы для некоторых сгенерированных проектов, а не для других

Я работал над кроссплатформенной системой сборки для нашего программного стека. В частности, я работаю над компонентом Windows системы сборки.

У нас есть несколько проектов, каждый из которых имеет ручной код .vcxproj. Некоторые из проектов зависят друг от друга, некоторые зависят от Qt.

Мои файлы .vcxproj работают нормально для трех из пяти проектов, которые я пробовал до сих пор, но провалились на двух других довольно забавным способом:

project\dir> msbuild /p:Configuration=Release /p:PropertyA=C:\path\to\project\root\ /p:Platform=x64 obj\project.vcxproj
Microsoft (R) Build Engine version 4.0.30319.17929
[Microsoft .NET Framework, version 4.0.30319.18047]
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 16.07.2013 11:13:43.
Project "C:\path\to\project\root\obj\project.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "C:\path\to\project\root\obj\x64_Int\Release_DLL_Int\".
InitializeBuildStatus:
Creating "C:\path\to\project\root\obj\x64_Int\Release_DLL_Int\project.unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\AMD64\CL.exe /c /I"include path A" /I"include path B" /Zi /nologo /W3 /WX- /sdl /O2 /Oi /D NDEBUG /D _CRT_SECURE_NO_WARNINGS /D QT_CORE_LIB /D _WINDLL /D _MBCS /Gm- /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fo"C:\path\to\project\root\obj\x64_Int\Release_DLL_Int\\" /Fd"C:\path\to\project\root\obj\x64\\project.pdb" /Gd /TP /errorReport:queue
/nologo

src\main\cpp\source_a.cpp src\main\cpp\source_b.cpp src\main\cpp\source_c.cpp ...
????????????????????????????????????
c1xx : fatal error C1083: Cannot open source file: '????????????????????????????????????': No such file or directory [C:\path\to\project\root\obj\project.vcxproj]
????????????????????????????????
c1xx : fatal error C1083: Cannot open source file: '????????????????????????????????': No such file or directory [C:\path\to\project\root\obj\project.vcxproj]
...

С одной из этих строк знаков вопроса для каждого исходного файла по одному знаку вопроса на символ в пути к исходному файлу.

Это в командной строке, но если я открою проект в Visual Studio (2012), я смогу увидеть символы такими, какие они есть на самом деле:

error C1083: Cannot open source file: '猀爀挀尀洀愀椀渀尀挀瀀瀀尀...⸀挀瀀瀀': No such file or directory
error C1083: Cannot open source file: '猀爀挀尀洀愀椀渀尀挀瀀瀀尀...⸀挀瀀瀀': No such file or directory
...

(Я исключил настоящие имена файлов, извините.)

Каждый символ в имени файла был заменен [последовательно] китайским символом. Это замена 1: 1 с постоянными отношениями между римскими и китайскими символами, т.е. \ -> а также cpp -> 挀瀀瀀,

Я запустил msbuild с подробным диагностическим описанием и нигде в 12000+ строках вывода, прежде чем в этих сообщениях об ошибках есть китайский символ — он несколько раз правильно перечисляет исходные файлы, прежде чем он выходит из строя.

Через проверенную временем технику отладки «комментируя материал в случайном порядке» я обнаружил, что если я вручную отредактирую файлы vcxproj, которые определенным образом завершатся с ошибкой, проблема исчезнет, ​​но соединение не будет выполнено, потому что я закомментировал пути к библиотекам или исходные файлы.

В обоих неудачных проектах удаление 4-6 исходных файлов (случайным образом, хотя это согласованно в том смысле, что комментирование одних и тех же четырех файлов всегда будет либо работать, либо нет) исправит это.
В той, которая зависит от Qt, удаление пути к $ (QT5DIR) / include / QtCore решит проблему, но не сможет связать, потому что не может найти Qt.

Все исходные файлы имеют кодировку ASCII, и, похоже, нет никакого согласованного форматирования в тех, которые устраняют проблему при удалении.

Я пробовал это на трех разных компьютерах, двух машинах с Windows 7 и предварительном просмотре 8.1. Он отлично работает на 8.1, но не работает на обеих машинах Win 7.

Похоже, это не связано с количеством файлов в проекте, потому что в одном из проектов, которые работают, имеется гораздо больше файлов, чем в любом из нерабочих.

Кажется, это не проблема зависимости, потому что только один из нерабочих зависит от Qt, и сходства между рабочим и нерабочим, похоже, исключают межпроектные зависимости.

Я понимаю, что это довольно красиво, любой гуру Microsoft знает, что происходит?

Вопрос 1: Что я делаю неправильно? Что может вызвать такое поведение?

Вопрос 2: Любые идеи о том, что я могу сделать, чтобы продолжить отслеживать проблему?

Обновления:

  • Если я запускаю строку ClCompile самостоятельно, она на самом деле пытается все скомпилировать, но не может найти стандартные библиотеки. Я думаю, что это означает, что эта проблема не происходит в этом случае.
  • Я нашел то, что считаю обходным решением: c1xx: фатальная ошибка C1083: невозможно открыть исходный файл — с некоторыми китайскими или яванскими но я все еще надеюсь, что кто-то ответит с реальным решением. Почему это происходит? Почему устранение, казалось бы, случайных частей .vcxproj исправляет это? Есть ли эвристика обнаружения кодирования, которая неправильно интерпретирует мои пути?

2

Решение

Я предполагаю, что ошибка форматирования текста. Обратная косая черта имеет значение U + 005C, а символ, в который она преобразуется, имеет значение U + 5C00 (согласно http://www.scarfboy.com/coding/unicode-tool?s=U%2B5C00 ). Та же проблема верна для «c» в cpp, и я уверен, что для «p» также.

Я не очень хорошо знаком с тем, какие текстовые кодировки поддерживает MSVC, но я бы начал с рассмотрения кодировки и проверки того, что они все одинаковые, а затем рассмотрения всего, что может неправильно преобразовывать файлы, скажем, программы, которая верит в это. работает с файлами ANSI вместо расширенной кодировки. Возможно, вам не хватает байта или порядок байтов вашего широкого символа может быть изменен.

1

Другие решения

Это была ошибка Microsoft!

http://connect.microsoft.com/VisualStudio/feedback/details/774527

Итак, сейчас я собираюсь пропустить новые строки в AdditionalOptions (хотя это работало для некоторых проектов …?)

Не рад этому как решению, но, похоже, работает.

1

По вопросам рекламы [email protected]