<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font size="-1">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.</font></p>
<p><font size="-1">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.<br>
</font></p>
<p><font size="-1">I am also using VMs (</font><font size="-1"><font
size="-1">kvm) </font>that increase the ease of using recent
distribution releases and isolates whatever clang and llvm
decides to do.<br>
</font></p>
<p><font size="-1"><a class="moz-txt-link-freetext" href="https://help.ubuntu.com/community/KVM/Installation">https://help.ubuntu.com/community/KVM/Installation</a></font></p>
<p><font size="-1">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.</font></p>
<p><font size="-1">Looks like a beta-release of Xubuntu 20.04 is
here.</font></p>
<p><font size="-1"><a class="moz-txt-link-freetext" href="https://xubuntu.org/news/xubuntu-20-04-testing-week/">https://xubuntu.org/news/xubuntu-20-04-testing-week/</a></font></p>
<p><font size="-1">I will see if it will fly.<br>
</font></p>
<p><font size="-1">Neil Nelson<br>
</font></p>
<div class="moz-cite-prefix"><font size="-1">On 4/4/20 3:11 PM,
Mehdi AMINI wrote:</font><br>
</div>
<blockquote type="cite"
cite="mid:CANF-O=YAdtB3aUbAcKMXepgqNQy-GwFUP1jDKKc9y+m1ShaHSQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat,
Apr 4, 2020 at 12:48 PM Neil Nelson via
llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<p><font size="-1">'Supported' means
that it comes from the packages
available from the distribution that
can be seen via this page.</font></p>
<p><font size="-1"><a
href="https://packages.ubuntu.com/"
target="_blank"
moz-do-not-send="true">https://packages.ubuntu.com/</a></font></p>
<p><font size="-1">These packages have
been processed by the Ubuntu
community to obtain a reliability
expectation that would not apply,
for example, to a PPA.</font></p>
</div>
</blockquote>
<div><br>
</div>
<div>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".</div>
<div>If I take Xenial for instance, the most
recent GCC version is 5.4.0 as far as I
can tell: <a
href="https://packages.ubuntu.com/xenial/devel/gcc-5"
moz-do-not-send="true">https://packages.ubuntu.com/xenial/devel/gcc-5</a>
; 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).</div>
<div> <br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<p><font size="-1">The difference
between installing or building Clang
and LLVM from original sources as
against installing versions
available from the distribution</font></p>
</div>
</blockquote>
<div>I don't understand this sentence?</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<p><font size="-1"> 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.</font></p>
</div>
</blockquote>
<div>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:</div>
<div><br>
</div>
<div># Inside llvm-project/</div>
<div>$ mkdir build/ && cd build/</div>
<div># bootstrap CMake</div>
<div>$ wget <a
href="https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0.tar.gz"
moz-do-not-send="true">https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0.tar.gz</a></div>
<div>$ echo
"b74c05b55115eacc4fa2b77a814981dbda05cdc95a53e279fe16b7b272f00847
cmake-3.17.0.tar.gz" | sha256sum -c </div>
<div>$ tar -xf cmake-3.17.0.tar.gz
&& cd cmake-3.17.0 &&
./bootstrap && make</div>
<div># Done, cmake is usable, *nothing* is
installed on the user system, everything
is self-contained *inside* the build
directory itself.</div>
<div>$ ./cmake-3.17.0/bin/cmake ../llvm/
-D.... # build LLVM as usual.</div>
<div><br>
</div>
<div><br>
</div>
<div> <br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<p><font size="-1">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.</font></p>
<p><font size="-1">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.</font></p>
<p><font size="-1">Those who lived
through that time remember it as the
dark-ages of long ago, never to be
seen again.</font> </p>
</div>
</blockquote>
<div>Been there, done that... (actually
suffered from that).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-- </div>
<div>Mehdi</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>