Building with cmake in vs2022

BTW: if anyone know a faster way to build on Windows that doesn’t involve weird issues every update I’m open for ideas.

When building latest in vs2022 with cmake:

set shared=
set shared=%shared% -DLLVM_TARGETS_TO_BUILD:STRING="AArch64;ARM;X86;WebAssembly;RISCV;Mips" -DLLVM_INCLUDE_EXAMPLES:BOOL="0"
set shared=%shared% -DLLVM_INCLUDE_GO_TESTS:BOOL="0" -DBUILD_SHARED_LIBS:BOOL="0" -DLLVM_EXTERNAL_LLD_SOURCE_DIR:PATH="c:/p/llvm-project/lld"
set shared=%shared% -DLLVM_INCLUDE_TESTS:BOOL="0" -DCMAKE_C_FLAGS:STRING="-frtti"
set shared=%shared% -DLLVM_USE_CRT_RELEASE:STRING="MT" -DLLVM_USE_CRT_RELWITHDEBINFO:STRING="MT"
set shared=%shared% -DLLVM_OPTIMIZED_TABLEGEN:BOOL="1"  -DLLVM_TOOL_LLD_BUILD:BOOL="1"  -DLLVM_TOOL_LLVM_C_TEST_BUILD:BOOL="0"  -Thost=x64 -G "Visual Studio 17 2022"

"c:\Program Files\CMake\bin\cmake.exe" -A Win32  -S ..\llvm-project\llvm -B ..\llvm-i386 %shared%

I get:

CustomBuild:
  "The build of 'C:\p\llvm-i386\CMakeFiles\4d2127988054da719750503d00685c65\LLVM-tablegen-host.rule' depends on 'C:\P\LLVM-I386\NATIVE\RELEASE\BIN\LLVM-TBLGEN' which is produced by the build of 'C:\p\llvm-i386\CMakeFiles\20a84e7a10f79388ca0cbd98442447b4\llvm-tblgen.rule'. The items cannot be built in parallel."
  Building native llvm-tblgen...
  Microsoft (R) Build Engine version 17.1.0+ae57d105c for .NET Framework
  Copyright (C) Microsoft Corporation. All rights reserved.
  
MSBUILD : error MSB1009: Project file does not exist. [C:\p\llvm-i386\utils\TableGen\LLVM-tablegen-host.vcxproj]
  Switch: llvm-tblgen.vcxproj
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(245,5): error MSB8066: Custom build for 'C:\p\llvm-i386\CMakeFiles\20a84e7a10f79388ca0cbd98442447b4\llvm-tblgen.rule;C:\p\llvm-i386\CMakeFiles\4d2127988054da719750503d00685c65\LLVM-tablegen-host.rule' exited with code 1. [C:\p\llvm-i386\utils\TableGen\LLVM-tablegen-host.vcxproj]
Done Building Project "C:\p\llvm-i386\utils\TableGen\LLVM-tablegen-host.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\p\llvm-i386\utils\TableGen\LLVM-tablegen-host.vcxproj.metaproj" (default targets) -- FAILED.
Done Building Project "C:\p\llvm-i386\lib\Target\AArch64\AArch64CommonTableGen.vcxproj.metaproj" (default targets) -- FAILED.

(after which the whole thing fails of course) C:\p\llvm-i386\utils\TableGen\LLVM-tablegen-host.vcxproj exists just fine.

Does anyone happen to know why this goes wrong? This always worked fine in the past.

I don’t know about your specific problem here. But I would 100% recommend you switch to the Ninja generator in CMake over the Visual Studio one since it’s way more tested. We only use this for windows now.

That sounds like a good idea. Do you happen to know how to pass stuff like what cpu and to emit debug info with ninja?

For CPU I just run vcvarsall.bat with the right argument in my command prompt before invoking CMake.

Debug info can be turned on for Debug or Release builds with -DLLVM_ENABLE_PDB=ON

Some general observations at v13.0.1:

Do you not see PDBs with the Debug config? That config should produce them.

Both Ninja and MSBuild will work, however with MSBuild, you’ll have a .sln file. Ninja is faster and, for me, creates smaller Release binaries–so there is that. I tend to use MSBuild since I prefer having a multiconfig .sln available for IDE source navigation. I use Ninja if I’m building the LLVM tooling or clang.

Do you need to build all architectures? Isolating required TARGETS_TO_BUILD will help with build time.

I have never tried on Windows to move to llvm-lld. However, I had one project (back at LLVM 7) on Windows that did use llvm-lld; at the time I moved to MS’s link because I believed it helped produce the PDBs. (If your requirements permit, I’d try switching to the default system linker–link.exe)

If you build the Debug config, you might want to use LLVM_USE_CRT_DEBUG:STRING=“MTd” for consistency.

If you frequently sync to the upstream LLVM (or otherwise have a changing git hash), I’d recommend having LLVM_APPEND_VC_REV as “false”. For me, having a changing git hash invalidate my builds and increased build times, in general.

I tend to separate my LLVM tools build from my LLVM lib/dev build. So, I’ll use stock LLVM to build clang, RT, etc. Then I’ll scale it back for just the LLVM component for a much faster compile. For me this results in very different configs and would be similar to using the community binaries and my own, smaller LLVM library build.

I’ve modified your settings and incorporated some of my comments from above. I also see issues with PDB generation in non-Debug builds–I thought I had a solution (LLVM_ENABLE_PDB and build with the IDE) I used on VS2019–there is an issue there. There is a mod to the CMakeLists that I’ve done as well. Otherwise, you should see the Debug build complete free of errors and have PDBs to work with.

Here is a modification to your config. The main difference is the linker and some project disablings.

set shared=
set shared=%shared% -DLLVM_TARGETS_TO_BUILD:STRING="X86"
set shared=%shared% -DLLVM_ENABLE_PROJECTS:STRING=""
set shared=%shared% -DBUILD_SHARED_LIBS:BOOL="0"
set shared=%shared% -DLLVM_APPEND_VC_REV:BOOL="0"
:: set shared=%shared% -DLLVM_BUILD_TOOLS:BOOL="0"
set shared=%shared% -DLLVM_BUILD_UTILS:BOOL="0"
set shared=%shared% -DLLVM_ENABLE_PDB:BOOL="1"
set shared=%shared% -DLLVM_INCLUDE_EXAMPLES:BOOL="0"
set shared=%shared% -DLLVM_INCLUDE_TESTS:BOOL="0"
set shared=%shared% -DLLVM_INCLUDE_TOOLS:BOOL="0"
set shared=%shared% -DLLVM_OPTIMIZED_TABLEGEN:BOOL="1"
:: set shared=%shared% -DLLVM_TOOL_LLVM_C_TEST_BUILD:BOOL="0"
:: set shared=%shared% -DLLVM_TOOL_LTO_BUILD:BOOL="0"
set shared=%shared% -DLLVM_USE_CRT_DEBUG:STRING="MTd"
set shared=%shared% -DLLVM_USE_CRT_RELEASE:STRING="MT"
set shared=%shared% -DLLVM_USE_CRT_RELWITHDEBINFO:STRING="MT"

:: cmake %shared% -G "Visual Studio 17 2022" -A x64 -Thost=x64 C:\Users\kippesp\projects\llvm-tutor\llvm-tutor.git\llvm_prebuild\build2\deps\llvm-project\src\llvm
:: cmake --build . --config Debug