[libc-commits] [libc] [llvm] [libc][cmake][linux] require new LLVM_LIBC_USE_HOST_KERNEL_HEADERS or LIBC_KERNEL_HEADERS (PR #123820)
Michael Jones via libc-commits
libc-commits at lists.llvm.org
Wed Jan 29 11:19:17 PST 2025
================
@@ -216,6 +216,27 @@ if (LIBC_TARGET_OS_IS_WINDOWS AND LLVM_LIBC_FULL_BUILD)
message(FATAL_ERROR "Windows does not support full mode build.")
endif ()
+if (LIBC_TARGET_OS_IS_LINUX)
----------------
michaelrj-google wrote:
My main concern is around default configurations. Currently, `LLVM_LIBC_FULL_BUILD` defaults to off, so overlay is the default. We should probably change that at some point, but that's a separate issue. The important thing is that our cmake shouldn't error if you don't specify any flags.
Currently, if you run `cmake ../runtimes -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLLVM_ENABLE_RUNTIMES="libc"` you get an overlay mode build with no allocator. It's not a particularly useful configuration, but it will build and pass our tests. This is important for two reasons:
1) First impressions are important, a build failure looks bad, and lots of people don't read the docs.
2) A surprising number of people download the `llvm-project` repo, set the enabled projects/runtimes to "all", and run `make install`. They then file bugs when they run into a build error, even if it's for a project they didn't even plan to use. This is annoying and wastes both their time and ours, so I'd like to avoid it if possible.
The other issue is that for overlay mode we do actually need to look at the other libc's headers. All of our type/macro headers in `libc/hdr/` use the system's headers in overlay mode, and a couple places (specifically in printf, assert, and a few other places iirc) even call functions from the system's libc. Overlay mode can't be hermetic, and I don't think we can practically make it independent of the system it's targeting.
https://github.com/llvm/llvm-project/pull/123820
More information about the libc-commits
mailing list