[llvm-dev] RFC: Updating to CMake 3.15.0

Robinson, Paul via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 4 06:33:32 PST 2019


Neil Nelson wrote:
> When I was managing IT and the servers for a small company that
> needed to be live 24/7 we used the latest Ubuntu LTS version
> because we needed rock-solid performance as best we could get.
> The software in the LTS version is tested and used by a large
> user base with necessary updates and so we expected to have high
> reliability.

I used to work for Tandem.  I understand that kind of environment.

> Those saying how easy it was to obtain the latest CMake have
> apparently not been faced with the absolute need for solid
> up-time. Installing hack-me-now, buggy, bleeding-edge software
> was severely discouraged. But in the LLVM environment, I can see
> where that is not a strong necessity.

However I think you are creating a false dichotomy. I have no real
insight into Ubuntu's methodology, but as a user, what I observe
is that Ubuntu LTS is NOT a collection of the most recent stable 
well-tested versions of all components, kept up-to-date; instead, 
it is a snapshot of stable, well-tested versions of all components, 
which Ubuntu then commits to maintaining for N years. A given LTS
releases maintenance updates only, not new features.

And it is certainly not the case that every version of every 
component after an Ubuntu LTS is a buggy, bleeding-edge untested 
hacked-up mess.  Ubuntu LTS chooses to stick with certain versions,
not because later versions are awful, but because picking up new
versions is not their goal.

So, when we talk about raising our minimum required CMake version,
it is not to take CMake bleeding-edge HEAD and have everyone build 
their own; it is to take a more recent formal release of CMake.  
Now, the CMake people might not conveniently package binaries for 
everyone's environment, which might mean some people need to pull 
a release's source package and build it themselves; this is the 
nature of open-source.  
--paulr



More information about the llvm-dev mailing list