[llvm-dev] [libcxx-dev] Bumping the CMake requirement for libc++ and libc++abi

[Neil Nelson via llvm-dev]

Not sure what the rush is. Ubuntu 20.04 will be available in a month 
with cmake 3.16.3 which appears to be recent enough to handle the issues 
indicated. Those on older distributions should upgrade as soon as they 
can and though that may take a few months, getting that coordinated all 
around does not seem that unreasonable.

The idea of downloading and installing individual pieces of software 
that are not verified through the distribution process has been 
discouraged for over a decade. Modern computer systems are far too 
complex including time and money to be taking unnecessary risks. The 
argument is never how easy it is to turn your computer into a boat 
anchor. It is what are the risks against the gain.

The gain could well be worth it. But without recognizing the risks there 
is no argument for gain. That others take risks we can avoid is not a 
good argument.

As an aside, a few days ago my new, custom built computer would not 
complete boot when it was just fine the day before and I was thinking: 
was it the Xubuntu update, was it my change to fstab, did my nvme ssd 
die, did I just toast several weeks of work, will my computer live 
again. It is not a happy situation.

Neil Nelson

On 3/26/20 9:03 AM, Nico Weber via llvm-dev wrote:
>
> FWIW, I agree that it's easy to install a non-system cmake and using 
> that (we do this on all our bots, and it's what people have to do on 
> mac and windows already)), and that "what is available in LTS distros" 
> shouldn't hold things up.
>
> For the actual rollout process, I could imagine that most folks would 
> miss the phab. So I'd suggest what we've done for similar changes in 
> the past:
>
> 1. Land a change that makes using an older cmake an error that goes 
> like "We'll require cmake $version soon. You can define 
> LLVM_SUPPRESS_CMAKE_$version_ERROR to turn this into a warning for a 
> few weeks, but update your bots soon"
>
> 2. Wait 2-4 weeks
>
> 3. Make the error unconditional (and remove the wording about the 
> suppression).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200326/12d4123b/attachment.html>