I work on a cross platform (Linux and Windows) project where we use the Intel compiler on both platforms along with Visual Studio 2019. We’ve almost finished migrating over to CMake (from QMake) and have run into an issue using the Ninja build.
Our initial development was against an older Visual Studio 2019 version, 16.2.5, which used Ninja 1.8.2. With that everything worked fine. Having moved up to a later version of Visual Studio, the version of Ninja has moved up and this is where the problems started.
I’ve done some investigation and the cause is down to the generated rules.ninja file which has deps = gcc specified for the dependency files that Ninja switched over to using from 1.9.0 onwards. I’ve had a look through some history of both Ninja and CMake and see that an amendment was made that gave a capability of switching back to deps = msvc but that only seems to be if there’s a space in the path of the source or target binary folder. For our configuration the source repos do not have a space in the path and hence the deps setting is defaulting to gcc on Windows. Unfortunately, this then causes us a problem as our build environment has both Intel oneAPI compiler installed and Microsoft Visual Studio 2019, which we initialise by calling Intel’s setvars.bat file which identified Visual Studio is installed and subsequently sets up Visual Studio paths.
When we then build, the build works, but the targets are always considered dirty as it cannot correctly parse some of the Microsoft headers due to spaces in the paths for those standard header files. Running a subsequent build then builds everything again despite us changing no source files.
I’ve created a small dummy project that exhibits this behaviour but am unable to upload it due to being new.
Is there a way to control the CMake ninja generator and make it write the deps setting out as msvc, either a compiler flag setting, or a CMake / ninja setting? If I revert our version of ninja.exe back to 1.8.2 everything works as expected, as it does if I introduce an arbitrary space in the source path for our actual source.
I don’t have the history or understanding as to why gcc mode is the default and only overridden (in Window-Intel-CXX.cmake) if there’s a space in the source path. My generated CMakeCXXCompiler.cmake has a CMAKE_CXX_SIMULATE_ID setting set to MSVC so I’d have thought that would be enough to identify to treat deps as msvc and not gcc.
I can post up the contents of my individual source files that exhibit the problem if it would help. You’d need the Intel oneAPI C++ compiler installed along with Visual Studio 2019 to replicate.
Thanks in advance