[llvm-dev] Upgrading LLVM's minimum required CMake version

Neil Nelson via llvm-dev llvm-dev at lists.llvm.org
Sat Apr 4 15:31:49 PDT 2020


I have seen here on the list that some are compiling on distribution 
versions older than 18.04. In using, for example, the Ubuntu 
distribution it is assumed that those interested in reliability and the 
more recent and better features will upgrade to the latest LTS version 
at the earliest convenience. For Xenial/16.04, the upgrade to 18.04 
should have been long ago.

I see you are taking precautions to restrict the cmake install for only 
clang and llvm and it looks reasonable. If this method is what is 
intended for clang and llvm, it would almost seem useful to make it part 
of the automated download procedure. It would become the standard with 
the rationale given as against other less restricted suggestions. Just 
saying get some particular cmake version does not obtain the suggested 
restricted requirement.

I am also using VMs (kvm) that increase the ease of using recent 
distribution releases and isolates whatever clang and llvm decides to do.

https://help.ubuntu.com/community/KVM/Installation

VMs have a number of advantages. A new ISO can be downloaded, a VM from 
the ISO running quickly, and then all the additional, interesting 
distribution software quickly installed on the VM without disturbing 
anything else. If for some reason that VM begins to have trouble, just 
delete it and try again. Keeping additional VMs in different stages of 
readiness helps the process along. Run the host on an LTS version if 
stability is desired or for other purposes, and the VMs having later 
versions with the wild software isolated.

Looks like a beta-release of Xubuntu 20.04 is here.

https://xubuntu.org/news/xubuntu-20-04-testing-week/

I will see if it will fly.

Neil Nelson

On 4/4/20 3:11 PM, Mehdi AMINI wrote:
>
>
> On Sat, Apr 4, 2020 at 12:48 PM Neil Nelson via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     'Supported' means that it comes from the packages available from
>     the distribution that can be seen via this page.
>
>     https://packages.ubuntu.com/
>
>     These packages have been processed by the Ubuntu community to
>     obtain a reliability expectation that would not apply, for
>     example, to a PPA.
>
>
> Right, so I'm looking for an answer to my question, I'll try make it 
> more concrete what I mean by "in cases where we already requires a 
> more recent compiler than the default one available".
> If I take Xenial for instance, the most recent GCC version is 5.4.0 as 
> far as I can tell: https://packages.ubuntu.com/xenial/devel/gcc-5 ; 
> assuming LLVM would move at some point to require a more recent 
> version than 5.4, it would mean that you couldn't build LLVM with the 
> packages available on Xenial. In this situation (which I referred to 
> as "cases where we already requires a more recent compiler than the 
> default one available") we already expect the user to get a toolchain 
> from a non-primary package source on this distribution, and if we do 
> this for the toolchain already I would expect that we should be able 
> to do it as well for CMake (again: for a given distribution/version).
>
>     The difference between installing or building Clang and LLVM from
>     original sources as against installing versions available from the
>     distribution
>
> I don't understand this sentence?
>
>     when compared to doing the same with cmake, is that the user
>     accepts the inherent risks from Clang and LLVM, but Clang and LLVM
>     can not accept the risks from the cmake group and then expect the
>     user to merely assume that there are no additional risks from
>     installing cmake.
>
> Maybe a nit here, but there is no need to *install* CMake: it could be 
> trivially build in the build directory. We are talking about a trivial 
> step here:
>
> # Inside llvm-project/
> $ mkdir build/ && cd build/
> # bootstrap CMake
> $ wget 
> https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0.tar.gz
> $ echo 
> "b74c05b55115eacc4fa2b77a814981dbda05cdc95a53e279fe16b7b272f00847 
>  cmake-3.17.0.tar.gz" | sha256sum -c
> $ tar -xf cmake-3.17.0.tar.gz && cd cmake-3.17.0 && ./bootstrap && make
> # Done, cmake is usable, *nothing* is installed on the user system, 
> everything is self-contained *inside* the build directory itself.
> $ ./cmake-3.17.0/bin/cmake ../llvm/ -D.... # build LLVM as usual.
>
>
>
>     The distributions are not merely just collections of software,
>     they are collections of software that have some guarantee of
>     working well together and without bugs and other issues because
>     they have been used and tested by that use in the distribution
>     community.
>
>     The importance of this distinction between the quality of software
>     expected in a distribution as against installing directly from
>     source is apparently lost on those who did not live through the
>     pre-distribution days. During that time we had to gather up the
>     dependencies ourselves, trying to get the correct versions, hoping
>     that the software compiled and worked with the other dependencies,
>     and hope we did not install malware and hackware. And quite often
>     it was a futile attempt to gather together software dependencies
>     of any size.
>
>     Those who lived through that time remember it as the dark-ages of
>     long ago, never to be seen again.
>
> Been there, done that... (actually suffered from that).
>
> I claim this is just not the same situation here: CMake is a 
> self-contained dependencies and as shown above does not need to escape 
> anywhere outside the build directory.
>
> -- 
> Mehdi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200404/4d1a4f58/attachment.html>


More information about the llvm-dev mailing list