Build failure with Ninja Multi-Config

Hi all, I just tried testing out Ninja Multi-Config for the first time on Windows. My project has worked with both the Ninja and Visual Studio 19 generators before without issue.

I try running in a developer command prompt:

> cmake -G "Ninja Multi-Config" ^
        -DCMAKE_TOOLCHAIN_FILE=D:/vcpkg/scripts/buildsystems/vcpkg.cmake ^
        -DWITH_TESTS=OFF ^
        -DWITH_UTILS=OFF ^
> cmake --build . --config Release

and after some time I get (manually wrapped)

cmd.exe /C "cmd.exe /C ""C:\Program Files\CMake\bin\cmake.exe" -E __create_def 
D:\Halide-build\src\CMakeFiles\Halide.dir\${CONFIGURATION}\exports.def.objs &&
cd D:\Halide-build" && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_dll 
--manifests  -- 
/nologo @CMakeFiles\Halide.rsp /out:bin\Release\Halide.dll /implib:src\Release\Halide.lib 
/pdb:bin\Release\Halide.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO  
/DEF:src\CMakeFiles\Halide.dir\$Release\exports.def   && cmd.exe /C "cd /D
D:\Halide-build\src && powershell -noprofile -executionpolicy Bypass -file 
D:/vcpkg/scripts/buildsystems/msbuild/applocal.ps1 -targetBinary 
D:/Halide-build/bin/Release/Halide.dll -installedDir 
D:/vcpkg/installed/x64-windows/bin -OutVariable out""

Couldn't open file 'src\runtime\CMakeFiles\Halide_initmod.dir\Debug\_initmod_aarch64_cpu_features_32_debug.cpp.obj' with CreateFile()

Where did \Debug\ come from in the output path? I specified Release at the command line.

For what it’s worth, these build commands work fine:

> cmake -G "Visual Studio 16 2019" -Thost=x64 -A x64 ^
        -DCMAKE_TOOLCHAIN_FILE=D:/vcpkg/scripts/buildsystems/vcpkg.cmake ^
        -DWITH_TESTS=OFF ^
        -DWITH_UTILS=OFF ^
> cmake --build . --config Release


> cmake -G Ninja -DCMAKE_BUILD_TYPE=Release ^
        -DCMAKE_TOOLCHAIN_FILE=D:/vcpkg/scripts/buildsystems/vcpkg.cmake ^
> cmake --build .

And here’s a link to the project on GitHub:
The CMakeLists.txt that created the target with the erroneous output path is here:

As far as I can tell, I’m not doing anything improper with CMAKE_BUILD_TYPE (prefer to use $<CONFIG> wherever that matters)

I’m taking a look at this now. I can’t think of anything off the top of my head that would cause this happen, but who knows.

What compiler are you using? Never mind, I see you’re using VS2019.

Thanks, Kyle. Let me know if you need any help reproducing the error.

I have successfully built LLVM 10.0.0 and configured Halide against it. Unfortunately, running cmake --build . --config Release sends CMake into an infinite loop of re-running CMake, and it never even has a chance to start the build. Is this a known bug in Halide?

Nope. That has never come up before. Can you tell me more about your environment, the commands you ran, etc.?

Oh… I think it might be an issue on my end. I cloned the repo while my computer was in UTC mode (I spend most of my time on Linux and rarely boot into Windows) but the build files have been generated after Windows set the correct time zone, leading to Ninja always thinking the source files have changed. I’ll see if re-cloning the repository helps.

Wow! Nice catch! I would never have guessed that one. I hate the timezone issues between Windows and Linux, too.

Confirmed, fixing the timestamps fixed it. I’m now waiting for the build.

Great, thanks for your effort on this.

I’m getting an error with a missing LLVM header:

C:\Users\kyle.edwards\development\halide\src\src\LLVM_Headers.h(28): fatal error C1083: Cannot open include file: 'llvm/ExecutionEngine/JITEventListener.h': No such file or directory

Any ideas?

Did you point Halide to a build directory of LLVM’s or an install directory?

Build directory

That would be the issue. LLVM isn’t really usable until it’s been installed somewhere. Try cmake --install . --prefix D:\llvm-install (for instance) and then set LLVM_DIR=D:\llvm-install\lib\cmake\llvm.

Also, LLVM’s Clang package is broken (missing ClangConfigVersion.cmake), so you need to set LLVM_DIR instead of CMAKE_PREFIX_PATH / CMAKE_MODULE_PATH. Various package managers seem to fix this somehow on their own (eg. Ubuntu and vcpkg)

OK, trying that now… and if the build tree for LLVM doesn’t work, someone should probably let the LLVM team know about that. If the build tree exports an LLVMConfig.cmake file, we’d expect it to work like the install file.

I have tried to open issues with them and they have all been ignored.

OK, I’ve reproduced the error, but with slightly different output:

Couldn't open file 'src\runtime\CMakeFiles\Halide_initmod.dir\RelWithDebInfo\_initmod_aarch64_cpu_features_32_debug.cpp.obj' with CreateFile()

For some reason mine tried to use RelWithDebInfo instead of Debug, but it’s close enough. I’m investigating now.

Great! Glad you could (mostly) repro. Thanks again for putting so much time into this.

One thing that would greatly help here is if you can create a minimal example that reproduces this. I would like to use it as a test case for the bugfix.

Scratch that, I have a minimal example:

cmake_minimum_required(VERSION 3.17)
project(test C)


add_library(testlib SHARED empty.c)

The problem is with CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS. I’ve opened cmake/cmake#20775 for this issue.