Skip to content

[libc] consider using runtimes/CMakeLists.txt as base (rather than llvm/CMakeLists.txt) #78479

Open
@nickdesaulniers

Description

@nickdesaulniers

we've observed issues in the past where flags set in llvm's cmake files end up polluting toolchain command line options for libc.

Via discussions with @ldionne on discord and #77810 (comment)

Yes, I've run into such pollution many times
This was one of the many motivating reasons for switching from LLVM_ENABLE_PROJECTS to LLVM_ENABLE_RUNTIMES, and using runtimes/CMakeLists.txt instead of llvm/CMakeLists.txt as a CMake root
It didn't solve everything, but at least it insulated the runtimes from arbitrary flags being added in other LLVM projects
We still have this issue due to e.g. HandleLLVMOptions.cmake
I think eventually the solution would be to ban global flags entirely. Modern CMake doesn't need that, it can define targets with flags and have them propagate to dependencies. It's a lot cleaner and safer
For most projects under the LLVM umbrella, being polluted by flags is an annoyance. For the runtimes, this can be actually dangerous cause you need to control exactly what flags you use for building.

I think this makes sense, however I'll note that other things can be polluted by the "rest" of LLVM as well:
Link flags
CMake variables like CMAKE_POSITION_INDEPENDENT_CODE
Other compiler flags that are not -D options
This is better than nothing, but I think the full fix is to gradually refactor the CMake files used by runtimes to avoid setting anything global.

We would have to update documentation, too. cc @petrhosek

Metadata

Metadata

Assignees

Labels

cmakeBuild system in general and CMake in particularlibc

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions