Commit b2bdd8bd39e90bfe3c66f6d5600468570a77ede6 breaks cmake configuration with error "Cannot create an empty builtins library"

[L00pZBreak3r]

libclc cannot be configured with cmake. cmake stops with error "Cannot create an empty builtins library".
I suspect that this issue appeared after this commit.

[AaronBallman]

CC @petrhosek as cmake maintainer

[frasercrmck]

Sorry, I just spotted this ticket. Are you still experiencing this issue?

To help us reproduce, which specific invocation of CMake were you using to build libclc?

[L00pZBreak3r]

Hi there!
I always use the latest CMake.
My build command line is:
cmake -S %F%.old\llvm -B %F%.build\build -G Ninja -DLLVM_ENABLE_PROJECTS="bolt;clang;clang-tools-extra;compiler-rt;libc;libclc;lldb;lld;mlir;openmp;polly;pstl;flang" -DCMAKE_INSTALL_PREFIX="%F%/llvm" -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=20

[frasercrmck]

Hi there! I always use the latest CMake. My build command line is: cmake -S %F%.old\llvm -B %F%.build\build -G Ninja -DLLVM_ENABLE_PROJECTS="bolt;clang;clang-tools-extra;compiler-rt;libc;libclc;lldb;lld;mlir;openmp;polly;pstl;flang" -DCMAKE_INSTALL_PREFIX="%F%/llvm" -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=20

Thanks. Is that still occurring on the latest main, though? I don't see any such CMake error (albeit on Linux - this looks like Windows?).

[L00pZBreak3r]

From the current github source tree:

CMake Error at F:/llvm-project.old/libclc/cmake/modules/AddLibclc.cmake:270 (message):
  Cannot create an empty builtins library
Call Stack (most recent call first):
  F:/llvm-project.old/libclc/CMakeLists.txt:362 (add_libclc_builtin_set)

It looks like Windows because it's Windows. :)

[frasercrmck]

Yep, confirmed!

I suspect it's a symlink thing - libclc/clspv64 symlinks to libclc/clspv and libclc/amdgcn-mesa3d symlinks to libclc/amdgcn-amdhsa. Without symlinks those will appear as empty directories. I know git on Windows doesn't always respect symlinks. What I don't know, however, is whether there's any LLVM policy about symlinks (others do exist in the source tree).

I think this has always been a problem in that it wouldn't be doing the right thing, but as you say, commit b2bdd8b broke the build by making it a configuration error - which I think shows it was a good thing to do.

I'll put up a PR to remove the symlinks - I don't think they're necessary.