Problems building project command line with Intel compiler and ninja generator

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

I do see logic that hinges on the Ninja version and that deps = gcc is broken with Intel when spaces are involved. However, maybe you can just force it back in your project (at the top-level)?

set(CMAKE_DEPFILE_FLAGS_C "/showIncludes")                                                                                            
set(CMAKE_C_DEPFILE_FORMAT msvc)

Repeat for each lang (replacing the _C_ part).

Thanks for the response Ben, sadly that’s made no difference for me, having set both C and C++ settings.

As far as I could tell when I last looked, I don’t think the depfile format could be manually specified but was instead evaluated by system/environment settings. I’m assuming that the decision on checking for spaces in the path was based off a particular known use case. I’ll play about with a bit more and if I can’t find a workable solution I’ll raise it as an issue with the ninja generator.

Amendment to my above post, your suggestion does work, I’d incorrectly used C++ rather than CXX when specifying the C++ depfile format so this does indeed provide me with a solution that I can control within our build config.

Thanks for the suggestion :slight_smile:

I’ve filed an issue: https://gitlab.kitware.com/cmake/cmake/-/issues/23948

Thanks Ben. Your above suggestion is working for us in the meantime so I’m happy our development team aren’t suffering repeated full rebuilds all the time.