[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