CMAKE_${lang}_CL_SHOWINCLUDES_PREFIX is not properly set for RC

[dmikushin]

In MSVC RC there is an issue with unfiltered command prefix. As the issue seems to be rather CMake/Ninja-specific, I have filled it there: https://gitlab.kitware.com/cmake/cmake/-/issues/21760

[mstorsjo]

Just FWIW, I've now reproduced this issue too (sorry for the long delay).

[mstorsjo]

As mentioned in #29, the issue seems to be that rules.ninja contains a command that looks like command = "" RC $in $DEP_FILE $out [...]. The "" is actually supposed to be a call to the cmcldeps executable that is shipped alongside cmake. But this executable is only built when cmake is built for Windows (and if I try to hack it to enable building it, it fails as it tries to include windows.h).

So the next steps would be to try to make the cmcldeps executable in cmake portable, so that it can be used in cross compilation too.

[mstorsjo]

Oh, there seems to be another workaround too - you can set -DCMAKE_NINJA_CMCLDEPS_RC=0 when configuring. The Windows-Clang.cmake file in cmake does this already, as cmcldeps isn't expected to exist when cross compiling, and with Windows-Clang it's expected that you might cross compile, while the Windows-MSVC.cmake file expects cmcldeps to exist by default.

[mstorsjo]

Even better. It seems pretty trivial to make CMake not set CMAKE_NINJA_CMCLDEPS_RC=1 automatically in these cases, see https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6843. I pushed such a commit at the end of my cmake branch with fixes too, as https://gitlab.kitware.com/mstorsjo/cmake/-/commit/8c1957b8026c60d50a705555a3a212c9217c0a2e. So by pointing the custom cmake build at that commit, the issue should go away. (And hopefully that fix soon is part of upstream cmake, if they're ok with the fix...)

[mstorsjo]

The fix in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6843 was merged now, so this will be fixed out of the box upstream since 3.23.0.