<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font size="-1">The next Ubuntu LTS release 20.04 will be
available April 23.</font></p>
<p><font size="-1"><a class="moz-txt-link-freetext" href="https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule">https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule</a></font></p>
<p><font size="-1">That release will have cmake version 3.16.3.</font></p>
<p><font size="-1"><a class="moz-txt-link-freetext" href="https://packages.ubuntu.com/search?suite=focal&arch=any&searchon=all&keywords=cmake">https://packages.ubuntu.com/search?suite=focal&arch=any&searchon=all&keywords=cmake</a></font></p>
<p><font size="-1">It may take 6 months or so for the LTS users to
upgrade in that the automatic update without reinstalling will
not be ready for a while. Some people can create a 20.04 VM as
soon as the release is available.</font></p>
<p><font size="-1">Neil Nelson<br>
</font></p>
<div class="moz-cite-prefix"><font size="-1">On 3/25/20 10:33 AM,
Pavel Labath via llvm-dev wrote:</font><br>
</div>
<blockquote type="cite"
cite="mid:826ab4f2-2641-920b-5251-c3ddc435bed6@labath.sk">
<pre class="moz-quote-pre" wrap="">If we're going to be updating the cmake version requirements llvm-wide
(and in particular, if we're going to make a policy out of that), I
think that should be done in a new RFC thread with an appropriate
subject -- people may not notice this discussion because they don't
follow libc++ and ignore any discussions relating to it.
As for the policy itself, I can't say I am fan of automatically bumping
version requirements, just because. A similar idea was proposed when we
were bumping the compiler versions, and was eventually rejected in favor
of the process described at
<a class="moz-txt-link-rfc2396E" href="https://llvm.org/docs/DeveloperPolicy.html#updating-toolchain-requirements"><https://llvm.org/docs/DeveloperPolicy.html#updating-toolchain-requirements></a>.
The current process involves proposing a specific version and discussing
the trade-offs implied by it.
Now, bumping the cmake version is not as involved as bumping the
compiler, but maybe it would be good if the process for doing it was
similar? If for nothing else, then for consistency?
regards,
Pavel
On 25/03/2020 17:04, Louis Dionne via llvm-dev wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Mar 25, 2020, at 12:00, Tom Stellard <<a class="moz-txt-link-abbreviated" href="mailto:tstellar@redhat.com">tstellar@redhat.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:tstellar@redhat.com"><mailto:tstellar@redhat.com></a>> wrote:
On 03/25/2020 06:20 AM, Louis Dionne wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Mar 25, 2020, at 00:47, Tom Stellard <<a class="moz-txt-link-abbreviated" href="mailto:tstellar@redhat.com">tstellar@redhat.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:tstellar@redhat.com"><mailto:tstellar@redhat.com></a>> wrote:
On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">In October, there was a discussion about updating CMake to 3.15:
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html">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.
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
Let's try to bump CMake for all of LLVM and see how that goes.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Yes, I agree we should bump the version for all of LLVM, but I don't
think we should bump the version without a long-term cmake usage plan.
e.g. something like: After every release branch, we bump the cmake
version
to whatever version of cmake is X months old.
I think the concern that this was our one chance to bump the CMake
version
led to the choice of 3.15 as the next version, which would be too
new for some Linux distros.
I think if we had a planned upgrade path, it would be easier for
those of us that
want something really new to settle on a release that is a little
bit older.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Ok, how about the following policy:
After every release branch, we bump the CMake version to whatever
version of CMake is 12 months old.
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 class="moz-txt-link-freetext" href="https://github.com/Kitware/CMake/releases/tag/v3.14.0">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.
Is everybody OK with the above policy? What would be the preferred
place to document it?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
12 months is fine with me.
I'm not sure the best place to document the policy. Some suggestions
are here:
<a class="moz-txt-link-freetext" href="https://llvm.org/docs/CMake.html">https://llvm.org/docs/CMake.html</a> or in the Programmer's manual.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Okay, so assuming nobody objects to this, the process would then be:
- I put up a Phabricator review updating the documentation and the
`cmake_minimum_required` fields for (all?) LLVM projects I can find.
- I wait for <some amount of time> before committing the change for
build bot owners to update their CMake
- I commit the change -- at that point using a too-old CMake will error
out and we can point any remaining failing bot to the policy
Does that sound like a reasonable plan? What should be the <some amount
of time>? I'd suggest something like two weeks to give folks ample time
to update builders.
Louis
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
-Tom
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Cheers,
Louis
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Tue, Mar 24, 2020 at 8:11 PM Louis Dionne via llvm-dev
<<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><mailto:llvm-dev@lists.llvm.org></a>
<a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><mailto:llvm-dev@lists.llvm.org></a>> wrote:
Hi,
The minimum CMake version currently advertised for libc++ and
libc++abi is currently 3.4.3. I think the oldest version of CMake
actually being tested on any builder is 3.7.0, so advertising 3.4.3
is somewhat of a lie (I'm pretty sure we're using features that
require a more recent version already). However, we do need to bump
it to 3.8.0 at least because CMake 3.7 doesn't know about C++17 in
its compilation features, and we'll need that to build libc++
properly going forward. This will mean for bot owners:
1. They need to upgrade CMake on the builders to at least 3.8.0
(which is really easy), or
2. they can disable processing of libc++ and libc++abi's CMake
files by making sure they do not appear in LLVM_ENABLE_PROJECTS
Any objections?
Cheers,
Louis
_______________________________________________
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-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><mailto:llvm-dev@lists.llvm.org></a>
<a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><mailto: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>
_______________________________________________
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-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><mailto: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>
</blockquote>
</blockquote>
</blockquote>
<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>
<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>