<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p><font size="-1">This repeats a discussion from late last year and
tends to revolve around a philosophy of how software
distribution should be done and the cmake issue has brought that
into focus. We may be able to glide past this issue with the
Ubuntu 20.04 LTS version due shortly and then save the cmake
issue for another day if it later needs to be revived.<br>
</font></p>
<p><font size="-1">Neil Nelson<br>
</font></p>
<div class="moz-cite-prefix"><font size="-1">On 3/25/20 11:14 AM,
Louis Dionne via llvm-dev wrote:</font><br>
</div>
<blockquote type="cite"
cite="mid:DA22652A-AE7B-4B22-8EF8-56C08EDBA9C4@apple.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 25, 2020, at 13:07, Nikita Popov <<a
href="mailto:nikita.ppv@gmail.com" class=""
moz-do-not-send="true">nikita.ppv@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" style="caret-color: rgb(0, 0, 0);
font-family: Helvetica; font-size: 12px; font-style:
normal; font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration: none;" class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020
at 5:01 PM Tom Stellard via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org" class=""
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br class="">
</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;">On 03/25/2020 06:20 AM, Louis
Dionne wrote:<br class="">
><span class="Apple-converted-space"> </span><br
class="">
><span class="Apple-converted-space"> </span><br
class="">
>> On Mar 25, 2020, at 00:47, Tom Stellard <<a
href="mailto:tstellar@redhat.com" target="_blank"
class="" moz-do-not-send="true">tstellar@redhat.com</a>>
wrote:<br class="">
>><br class="">
>> On 03/24/2020 09:00 PM, Petr Hosek via
llvm-dev wrote:<br class="">
>>> In October, there was a discussion about
updating CMake to 3.15:<span
class="Apple-converted-space"> </span><a
href="http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html"
rel="noreferrer" target="_blank" class=""
moz-do-not-send="true">http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html</a>.
No decision was made, but maybe we should revisit that
proposal? If we're going to require a newer version of
CMake for some subprojects, I'd prefer to bump the
minimum CMake version for all of LLVM.<br class="">
><span class="Apple-converted-space"> </span><br
class="">
> My personal opinion is that there's a tendency to
view all subprojects under the LLVM umbrella as a
single, monolithic project. That leads to the desire
to make decisions for the whole project, which is
often difficult, as opposed to making the right
decision for each subproject, which is often easier.
This results on subprojects being blocked from doing
the right thing for them, like we've seen happen for
pre-commit CI. But that's a much larger
(non-technical) discussion than the scope of a simple
CMake version bump.<br class="">
><span class="Apple-converted-space"> </span><br
class="">
> Let's try to bump CMake for all of LLVM and see
how that goes.<br class="">
><span class="Apple-converted-space"> </span><br
class="">
>> Yes, I agree we should bump the version for
all of LLVM, but I don't<br class="">
>> think we should bump the version without a
long-term cmake usage plan.<br class="">
>> e.g. something like: After every release
branch, we bump the cmake version<br class="">
>> to whatever version of cmake is X months old.<br
class="">
>><br class="">
>> I think the concern that this was our one
chance to bump the CMake version<br class="">
>> led to the choice of 3.15 as the next
version, which would be too new for some Linux
distros.<br class="">
>> I think if we had a planned upgrade path, it
would be easier for those of us that<br class="">
>> want something really new to settle on a
release that is a little bit older.<br class="">
><span class="Apple-converted-space"> </span><br
class="">
> Ok, how about the following policy:<br class="">
><span class="Apple-converted-space"> </span><br
class="">
> After every release branch, we bump the CMake
version to whatever version of CMake is 12 months old.<br
class="">
><span class="Apple-converted-space"> </span><br
class="">
> This is simple, straightforward, and it gives a
full year of old CMakes being supported. If we did
this right now, this would take us to CMake 3.14.0,
released around March 14th, 2019 (<a
href="https://github.com/Kitware/CMake/releases/tag/v3.14.0"
rel="noreferrer" target="_blank" class=""
moz-do-not-send="true">https://github.com/Kitware/CMake/releases/tag/v3.14.0</a>).
I believe the expectation should be that recent CMakes
are upgraded using some package manager or download
from the site -- we can't really expect the CMake
version to be the one provided by the system, because
that is either non-existent or very old on most Linux
distributions AFAICT. Fortunately, installing a new
CMake is incredibly easy.<br class="">
><span class="Apple-converted-space"> </span><br
class="">
> Is everybody OK with the above policy? What would
be the preferred place to document it?<br class="">
><span class="Apple-converted-space"> </span><br
class="">
<br class="">
12 months is fine with me.<br class="">
<br class="">
I'm not sure the best place to document the policy.
Some suggestions are here:<br class="">
<a href="https://llvm.org/docs/CMake.html"
rel="noreferrer" target="_blank" class=""
moz-do-not-send="true">https://llvm.org/docs/CMake.html</a><span
class="Apple-converted-space"> </span>or in the
Programmer's manual.<br class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">I think the relevant metric here needs to
be "which version is available on current LTS
distros", and not "how old is the release". The
current cmake version I have on Ubuntu 18.04 is cmake
3.10.2, so I personally would be happy with a bump to
that version, but not something newer. People using
other distributions probably have other
considerations. If someone wants to perform a cmake
version bump, I believe the first step would be to
gather what the cmake version availability across
distros looks like right now, so an informed decision
can be made.<br class="">
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I'll actually suggest that we might want to do something
else entirely. If we depend on the version available in
distros, then we are at the mercy of those distros not
updating. It also means that we need to look at several
distributions and try to satisfy everybody. That's a lot
harder than requiring that people download a recent CMake from
<a href="http://cmake.org" class="" moz-do-not-send="true">cmake.org</a>.</div>
<div><br class="">
</div>
<div>CMake has the benefit of being incredibly easy to install,
either from source or with the binaries provided on their
website. Do you think it's an unreasonable requirement to ask
folks to download CMake instead of using the one provided with
their OS?</div>
</div>
<br class="">
<div class="">Louis</div>
<div class=""><br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</body>
</html>