[llvm] cmake: Derive CMake system name from a triple via new mechanism (PR #208773)
Matt Arsenault via llvm-commits
llvm-commits at lists.llvm.org
Sun Aug 2 11:58:24 PDT 2026
arsenm wrote:
> In addition to introducing a hard dependency on Python,
> but shouldn't be required to build LLVM,
As of this change, this is just adding an unused script. The natural follow up patch would introduce the use, which would only be needed in the runtimes build, not LLVM proper.
> this change also ties LLVM and CMake closer together without a clear contract.
I think the contract is quite straightforward.The runtimes build is constructing a cmake invocation for a specific triple, and the build needs to determine the name that the in-use cmake wants to use. That would require cmake version knowledge if cmake introduces new system names. The TargetParser def only functions to prevent adding new entries that get out of sync, it's not load bearing and llvm isn't using the cmake name.
> To give a concrete example, say the next release of CMake adds platform support for UEFI (this is a very likely scenario since that's something we're working on); would we immediately update `llvm/include/llvm/TargetParser/TripleName.def` and break anyone using older CMake versions, or would we follow the LLVM's `cmake_minimum_required` which means the new mechanism wouldn't be helpful until LLVM bumps the minimum CMake version? I believe this deserves an RFC and the policy needs to be properly documented.
In the cmake-introduces-new-OS-support case, the script should fall through to use Generic, which is a better behavior vs. the status quo of inheriting the host. But ideally the script would be updated to consider the active version
> am unsure a core file like llvm/include/llvm/TargetParser/ should have bake-in cmake knowledge. (This would be very bad if bazel/gn followed suit...)
The point of putting it there is it strongly prevents it getting out of sync if someone adds a new triple field. LLVM only has cmake as the one true build system. The others are tolerated but aren't supposed to impose direct requirements. Do those even have a runtimes build?
https://github.com/llvm/llvm-project/pull/208773
More information about the llvm-commits
mailing list