Skip to content

Ninja / cmcldeps unable to determine implicit dependencies of UTF-16 .rc files when using clang-cl

While the resource compiler itself is able to process UTF-16 source files clang-cl (standing in for cl) is currently not.

Since rc does not itself provide the means to output implicit dependency information cmake (in context of the Ninja generator) uses the cmcldeps tool.

cmcldeps uses the C/C++ compiler to preprocess resource files and determine their implicit dependencies.

Corresponding clang-cl diagnostic when it hits an UTF-16 encoded .rc file:

fatal error: UTF-16 (LE) byte order mark detected in 'c:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.14.26428\ATLMFC\include\afxres.rc', but encoding is not supported

Not entirely sure yet if there is anything sensible CMake could do in this context. Perhaps the scanner used by the Makefile generators could be used (presumably it doesn't handle UTF-16 either but fails silently?; which I'd be OK with in my specific case as well) or cmcldeps could invoke Microsoft's cl even when clang-cl is used for C/C++.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information