[llvm-dev] RFC: Updating to CMake 3.15.0

[Chris Bieneman via llvm-dev]

> On Oct 30, 2019, at 12:02 PM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Here's an argument for why to *lower* the minimum supported CMake version:

No offense, but that isn't going to happen.

> 
> LLVM is a compiler backend.

LLVM is *much* more than a compiler backend. Using LLVM as a compiler backend is one use of LLVM. It is also a JIT infrastructure, an object file toolchain, the underlying bits of a linker and a debugger. It is widely used in a lot of situations.

> 
> LLVM is already the most difficult dependency to provide for most
> projects that use it as a compiler backend. This is certainly true for
> Zig, for example. This makes the requirements of building LLVM a
> bottleneck in the bootstrapping process.
> 
> Any bump in minimum required CMake version increases the requirements of
> the system to bootstrap a project which depends on LLVM.

Except that modern CMake's build requirements are a subset of LLVMs. Meaning if you have everything you need to build LLVM except CMake, you have everything you need to build a modern CMake.

> 
> For programming languages, a more minimal bootstrapping process is a
> feature.
> 
> Therefore, bumping the minimum required CMake version of LLVM *removes a
> feature* from any languages that depend on LLVM. This is O(N) cost where
> N is the number of projects that depend on LLVM.
> 
> Zig has cmake_minimum_required(VERSION 2.8.5). LLVM's higher CMake
> requirement is already the most demanding CMake version of all Zig's
> dependencies. Making it any higher than it already is is strictly worse.
> 
> Why is newer CMake needed? What is LLVM's build process doing that is so
> complicated that it needs bleeding edge CMake?

CMake wasn't really designed to accurately represent all of the things that LLVM does in its build process. Here is a list of a few things LLVM projects do in CMake that we've had to implement hacks to work around in the past:

(1) LLVM builds a DSL compiler then uses that compiler to generate source files. CMake historically couldn't represent those dependencies correctly, and still can't in the Xcode generator
(2) The compiler-rt builtins libraries need to be configured and built with a not fully functioning C toolchain, as Petr Hosek pointed out CMake 3.14 resolves that by adding CMAKE_TRY_COMPILE_TARGET_TYPE
(3) MSVC support has been constantly evolving since 2.8, and various releases have made huge strides in making it work
(4) LLDB generates an macOS framework target which was almost completely broken before CMake 3.8

We've had lots of reasons in the past to update, and virtually none to stay on old versions. If building CMake from source was a prohibitively difficult problem, or CMake itself had wild requirements to bootstrap I'd probably argue differently about this. That just isn't the case. Holding ourselves to an old version of CMake is a maintenance burden on our community and IMO provides little benefit to our users.

-Chris

> 
> Regards,
> Andrew
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191103/1778f20b/attachment.html>