<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Monaco;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Kitware has a vested interest in ensuring that their product works correctly for the majority of its users. Canonical has a vested interest in ensuring that their supported distros work correctly for their users. The sets of systems that
these to separate organizations choose to actually support well may not entirely overlap, and that’s a problem for those people who fall outside the overlapping region of that Venn diagram.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One can reasonably assume that if they are using a distro that is within it’s supported lifetime, then CMake from the repos works correctly. It’s not safe to assume that if they are using a distro that is within it’s supported lifetime,
then CMake from Kitware’s PPA works correctly in that distro; Ktiware may have stopped testing “old” distros.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Personally, I’d rather build from source myself than vet a PPA. Especially for something as easy to build as CMake.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Shoaib Meenai <smeenai@fb.com> <br>
<b>Sent:</b> Monday, April 6, 2020 12:57 PM<br>
<b>To:</b> Chris Tetreault <ctetreau@quicinc.com>; Mehdi AMINI <joker.eph@gmail.com>; Neil Nelson <nnelson@infowest.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake version<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What if CMake themselves are providing the APT packages (<a href="https://apt.kitware.com/">https://apt.kitware.com/</a>)? I’m assuming it still counts as third-party, but it should carry some more weight if the creators of the software
(who after all know best how it works and what dependencies it needs) are packaging it.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Chris Tetreault via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
<b>Reply-To: </b>Chris Tetreault <<a href="mailto:ctetreau@quicinc.com">ctetreau@quicinc.com</a>><br>
<b>Date: </b>Monday, April 6, 2020 at 12:49 PM<br>
<b>To: </b>Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>>, Neil Nelson <<a href="mailto:nnelson@infowest.com">nnelson@infowest.com</a>><br>
<b>Cc: </b>"<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
<b>Subject: </b>Re: [llvm-dev] Upgrading LLVM's minimum required CMake version<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in">Every additional dependency that we force the user to manually install (either by building from source, or adding some new PPA to their ubuntu system), raises the barrier to entry that much higher. Just because
we may require the user to manually install some newer compiler on their system doesn’t mean that we should also require them to install some newer CMake than what’s on their system. (unless it is actually necessary, but we’ve beaten that dead horse long enough)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">I agree with Neil’s interpretation that the definition of “supported” being used here is default system packages and not third party repos that claim to work for that system.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>>
<b>On Behalf Of </b>Mehdi AMINI via llvm-dev<br>
<b>Sent:</b> Saturday, April 4, 2020 2:11 PM<br>
<b>To:</b> Neil Nelson <<a href="mailto:nnelson@infowest.com">nnelson@infowest.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake version<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Sat, Apr 4, 2020 at 12:48 PM Neil Nelson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p style="margin-left:.5in"><span style="font-size:10.0pt">'Supported' means that it comes from the packages available from the distribution that can be seen via this page.</span><o:p></o:p></p>
<p style="margin-left:.5in"><span style="font-size:10.0pt"><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__packages.ubuntu.com_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=et1KT2BvL-b2rRsPZAv8zmIauCDJSuF9FAT2IpHStVc&s=J6y2IT0KPqyjhuOu9zv33nKwsufxKDBGYfVN79wpo_E&e=" target="_blank">https://packages.ubuntu.com/</a></span><o:p></o:p></p>
<p style="margin-left:.5in"><span style="font-size:10.0pt">These packages have been processed by the Ubuntu community to obtain a reliability expectation that would not apply, for example, to a PPA.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">If I take Xenial for instance, the most recent GCC version is 5.4.0 as far as I can tell:
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__packages.ubuntu.com_xenial_devel_gcc-2D5&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=et1KT2BvL-b2rRsPZAv8zmIauCDJSuF9FAT2IpHStVc&s=-KH3heHigoIJjr3LQKQrm918NvxEI-SeruNINqx5Bso&e=">
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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p style="margin-left:.5in"><span style="font-size:10.0pt">The difference between installing or building Clang and LLVM from original sources as against installing versions available from the distribution</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in">I don't understand this sentence?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p style="margin-left:.5in"><span style="font-size:10.0pt">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.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in">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:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"># Inside llvm-project/<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">$ mkdir build/ && cd build/<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"># bootstrap CMake<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">$ wget <a href="https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0.tar.gz">
https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0.tar.gz</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">$ echo "b74c05b55115eacc4fa2b77a814981dbda05cdc95a53e279fe16b7b272f00847 cmake-3.17.0.tar.gz" | sha256sum -c <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">$ tar -xf cmake-3.17.0.tar.gz && cd cmake-3.17.0 && ./bootstrap && make<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"># Done, cmake is usable, *nothing* is installed on the user system, everything is self-contained *inside* the build directory itself.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">$ ./cmake-3.17.0/bin/cmake ../llvm/ -D.... # build LLVM as usual.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p style="margin-left:.5in"><span style="font-size:10.0pt">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.</span><o:p></o:p></p>
<p style="margin-left:.5in"><span style="font-size:10.0pt">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.</span><o:p></o:p></p>
<p style="margin-left:.5in"><span style="font-size:10.0pt">Those who lived through that time remember it as the dark-ages of long ago, never to be seen again.</span> <o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in">Been there, done that... (actually suffered from that).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">-- <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Mehdi<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt">On 4/4/20 11:48 AM, Mehdi AMINI via llvm-dev wrote:</span><o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Thu, Apr 2, 2020 at 10:49 AM Shoaib Meenai via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
I’m in favor of all this. Thanks for volunteering! I’m happy to help out in whatever way.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
Some things it might be worth figuring out for future upgrades:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
* If we want to limit ourselves to CMake versions supported by LTS releases of distros, which distros should we consider, and how far back should we go (i.e. is it just the latest LTS or the last two LTS versions)?<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Can you clarify what "supported" means? Does it include PPA on ubuntu for example?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I wouldn't limit ourselves artificially to the version of CMake "natively" available on an OS in cases where we already requires a more recent compiler than the default one available: if we consider OK to require
as user to build clang or gcc from source or use a PPA, we should be OK the same way with CMake.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
* For platforms like Ubuntu where CMake publishes its own packages (that you can install via the platform’s package manager), do those count, or do we only consider the CMake that comes in the OS packages?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
* Do we have any limitations around how often/when we upgrade? You’re tying the upgrade to after the branch, which is pretty standard, but e.g. if we wanted to upgrade to 3.8.0 now and then upgrade to 3.13.4 after the branch, would people be okay with that,
or should we limit upgrades to just shortly after a branch?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
<o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
<b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black"><<a href="mailto:ldionne@apple.com" target="_blank">ldionne@apple.com</a>> on behalf of Louis Dionne <<a href="mailto:ldionne@apple.com" target="_blank">ldionne@apple.com</a>><br>
<b>Date: </b>Thursday, April 2, 2020 at 7:20 AM<br>
<b>To: </b>Shoaib Meenai <<a href="mailto:smeenai@fb.com" target="_blank">smeenai@fb.com</a>><br>
<b>Cc: </b>"<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, Chris Bieneman <<a href="mailto:beanz@apple.com" target="_blank">beanz@apple.com</a>>,
Petr Hosek <<a href="mailto:phosek@chromium.org" target="_blank">phosek@chromium.org</a>>, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" target="_blank">compnerd@compnerd.org</a>>, "<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>"
<<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>><br>
<b>Subject: </b>Re: Upgrading LLVM's minimum required CMake version</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
Okay, so we've had some discussion on this thread, and although some people (including me) would like a more aggressive policy, I believe the following will not get any objection (based on the thread). On April 23rd 2020, Ubuntu 20.04 LTS will ship with CMake
3.16.x. This will make the lower bound for LTS distributions be 3.13.4, and so I suggest we upgrade to that. Here's a proposed process:
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
1. Immediately add a CMake warning in <span style="font-family:"Monaco",serif"><root>/llvm/CMakeLists.txt</span> saying that CMake 3.13.4 will be the new minimum version starting with LLVM 12.0.0, and mentioning the versions used in various LTSes.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
2. Immediately send a courtesy heads-up email to all build-bot owners telling them about the upcoming change.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
3. Right after we branch off the release branch for LLVM 11.0.0 (the next one), make the minimum CMake version required be 3.13.4.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
4. Iterate on (3) until all bots are migrated.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
5. Send a message to the list saying the bump is complete. At that time, projects are free to start using features from 3.13.4.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
Unless someone else absolutely wants to bite the bullet, I volunteer to do the above steps.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
Thoughts?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
Louis<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
<o:p></o:p></p>
</div>
<div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
On Mar 26, 2020, at 16:07, Shoaib Meenai <<a href="mailto:smeenai@fb.com" target="_blank">smeenai@fb.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:1.0in">
We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which point people suggested upgrading the CMake version used by all of LLVM), so let’s try
to move this forward.<br>
<br>
Our current required minimum version is CMake 3.4.3, which was released on January 25th 2016. It’s interesting to note that LLVM started requiring 3.4.3 on May 31st 2016, which was just 4 months after its release.<br>
<br>
Let’s look at the CMake versions available on various distros and operating systems. I’m unfamiliar with many of these, so I apologize if I get something wrong. (I’m using
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__pkgs.org&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=S6Qvuq5DqECZFfItkAJOL5xjTSp1psRWYtq_WOnXt_o&e=" target="_blank">
pkgs.org</a> for most of this information.)<br>
* RHEL 6 (released Nov 10th 2010) : 3.6.1 (via EPEL)<br>
* RHEL 7 (released June 10th 2014): 3.14.7 (via EPEL)<br>
* RHEL 8 (released May 7th 2019): 3.11.4 (maybe <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__pkgs.org&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=S6Qvuq5DqECZFfItkAJOL5xjTSp1psRWYtq_WOnXt_o&e=" target="_blank">
pkgs.org</a> is screwy on this one, because it doesn’t make sense that RHEL 7 should have a newer available version than RHEL 8)<br>
* Debian 9 (released June 17th 2017): 3.7.2<br>
* Debian 10 (released July 6th 2019): 3.13.4<br>
* Ubuntu 16.04 LTS (released April 21st 2016): 3.5.1<br>
* Ubuntu 18.04 LTS (released April 26th 2018): 3.10.2<br>
* FreeBSD 11 (released October 10th 2016): 3.15.5 (presumably upgraded in a point release)<br>
* FreeBSD 12 (released December 11th 2018): 3.15.5 (presumably upgraded in a point release)<br>
* NetBSD 8.1 (released May 31st 2019): 3.16.1<br>
* NetBSD 9.0 (released February 14th 2020): 3.16.1<br>
* OpenBSD: couldn’t find the version<br>
* macOS: latest version is readily available through Homebrew<br>
* Windows: You can install it yourself or use the one bundled with Visual Studio. I don't know what versions are bundled with Visual Studio; some searching suggests Visual Studio 2017 has CMake 3.12 and Visual Studio 2019 has 3.15, though I have no confirmation
of that.<br>
<br>
Note that CMake provides prebuilt binaries for Linux, macOS, and Windows, and it’s also straightforward to build from source (it has very conservative compiler requirements). One suggestion that was brought up in the past was for LLVM’s build system to just
download a newer version of CMake if you attempted to build it using one that was too old, but there was opposition [1]. There was also a suggestion to have a script in LLVM to download and build CMake for you, but there were mixed opinions on this too [2],
particularly since many developers might prefer downloading a binary release to building from source themselves (though of course the script could also download binary releases if applicable). I personally think downloading or building CMake yourself isn’t
a high barrier for anyone wanting to build LLVM (and in particular it’s *much* more straightforward than building LLVM itself), but I can understand why people would prefer to stick to versions available in distros.<br>
<br>
Another suggestion that came up last time was to set a policy for upgrading CMake versions on some regular basis. The opposition to this was that we should upgrade CMake versions only when a newer version has a compelling enough feature to justify upgrading,
rather than always upgrading. I can see arguments for both approaches, but we should definitely at least think about the benefits we can get from upgrading versions. I've gone through the CMake release notes and highlighted features which seemed potentially
valuable for LLVM. Note that I'm only highlighting features for which our minimum CMake version would have to be bumped up in order for our build system to take advantage of. There are other useful features in newer CMake versions, but you can take advantage
of them just by using a newer CMake yourself. For example, 3.9 loosens the dependencies of object compilation, which should result in faster Ninja builds.
<br>
<br>
CMake 3.5 (released March 8th 2016):<br>
* install(DIRECTORY) supports generator expressions<br>
<br>
CMake 3.6 (released July 7th 2016):<br>
* install() supports EXCLUDE_FROM_ALL<br>
* list() supports FILTER to filter by regular expression<br>
* Subninja support, which could theoretically be used for much faster runtimes builds, although in practice we probably want to make ExternalProject support this directly instead of trying to layer our own meta-build system on top<br>
* CMAKE_TRY_COMPILE_TARGET_TYPE to tell try_compile to build a static library instead of an executable, which will greatly simplify the compiler-rt build<br>
<br>
CMake 3.7 (released November 11th 2016):<br>
* New if() comparison operators LESS_EQUAL, GREATER_EQUAL, STRLESS_EQUAL, STRGREATER_EQUAL, VERSION_LESS_EQUAL, and VERSION_GREATER_EQUAL<br>
<br>
CMake 3.8 (released April 10th 2017):<br>
* Compile features for C++17, which is required to build libc++ correctly<br>
* Support for compile features for specific C++ features instead of only being able to specify standard versions<br>
* rpath support via BUILD_RPATH target property and CMAKE_BUILD_RPATH variable<br>
* Apple framework support for static libraries<br>
* New swig_add_library command in the UseSWIG module<br>
* New generator expression $<IF:cond,true-value,false-value><br>
<br>
CMake 3.9 (released July 18th 2017):<br>
* install(TARGETS) and install(EXPORTS) support for object libraries, which will simplify the compiler-rt build<br>
* TARGET_OBJECTS generator expression support in add_custom_command and file(GENERATE)<br>
* $<TARGET_BUNDLE_DIR:tgt> and $<TARGET_BUNDLE_CONTENT_DIR:tgt> generator expressions for Apple bundles<br>
<br>
CMake 3.10 (released November 20th 2017):<br>
* include_guard() command for proper guarding against double includes of CMake scripts<br>
* An interesting aside is that this is the first verion of CMake to require C++11 to build, which should give a good sense of how conservative they are about compiler requirements<br>
<br>
CMake 3.11 (released March 28th 2018):<br>
* add_library() and add_executable() can be called without sources as long as target_sources() is used later<br>
* target_compile_{definitions,features,options}, target_include_directories(), target_sources(), and target_link_libraries() can set the corresponding INTERFACE_* properties on imported targets<br>
* COMPILE_DEFINITIONS supports generator expressions<br>
* COMPILE_OPTIONS source file property added<br>
* INCLUDE_DIRECTORIES source file property added<br>
* Interface libraries support custom properites<br>
<br>
CMake 3.12 (released July 17th 2018):<br>
* add_compile_definitions() added to add compile definitions for targets (to avoid the global pollution caused by add_definitions())<br>
* cmake_minimum_required() supports a version range to indicate tested CMake versions and set policies accordingly<br>
* file(TOUCH) and file(TOUCH_NOCREATE) added<br>
* list(JOIN), list(SUBLIST) and list(TRANSFORM) added<br>
* string(JOIN) added<br>
* SHELL: prefix support in target_compile_options to avoid errant deduplication<br>
* target_link_libraries() supports object libraries and propagates usage requirements<br>
* EXPORT_PROPERTIES target property to control the target properties exported by export() and install(EXPORT)<br>
* FindLibXml2 provides imported targets<br>
* New FindPython, FindPython2, and FindPython3 modules to ease location Python and selecting a specific version<br>
* Modernization of UseSWIG module<br>
* New generator expressions $<GENEX_EVAL:...>, $<TARGET_GENEX_EVAL:target,...>, $<IN_LIST:...>, $<TARGET_EXISTS:...> and $<TARGET_NAME_IF_EXISTS:...><br>
* Compile features support for C++20<br>
<br>
CMake 3.13 (released November 20th 2018):<br>
* cmake -E create_symlink supported on Windows<br>
* target_link_directories() and target_link_options() commands to set link options instead of awkwardly having to use target_link_libraries() for this purpose<br>
* UseSWIG can manage INCLUDE_DIRECTORIES for SWIG compilation<br>
<br>
CMake 3.14 (released March 14th 2019):<br>
* file(CREATE_LINK) to create hard or symbolic links<br>
* if(DEFINED CACHE{VAR}) for checking if a cache variable is defined<br>
* $<IN_LIST:...> generator expression correctly handles empty argument<br>
* Fixes for object library linking propagation<br>
* Link options to manage position independent executables added automatically<br>
<br>
CMake 3.15 (released July 17th 2019):<br>
* list(PREPEND), list(POP_FRONT) and list(POP_BACK) added<br>
* New message() types NOTICE, VERBOSE, DEBUG and TRACE<br>
* string(REPEAT) added<br>
* MSVC_RUNTIME_LIBRARY target property and CMAKE_MSVC_RUNTIME_LIBRARY variable to select the runtime library type for MSVC<br>
* $<C_COMPILER_ID:...>, $<CXX_COMPILER_ID:...>, $<COMPILE_LANGUAGE:...>, and $<PLATFORM_ID:...> generator expressions support matching one value from a list<br>
* $<COMPILE_LANG_AND_ID:...> generator expression added<br>
* $<FILTER:list,INCLUDE|EXCLUDE,regex> generator expression added<br>
* $<REMOVE_DUPLICATES:list> generator expression added<br>
* New $<TARGET_FILE*> generator expressions added: $<TARGET_FILE_PREFIX:...>, $<TARGET_FILE_BASE_NAME:...>, $<TARGET_FILE_SUFFIX:...>, $<TARGET_LINKER_FILE_PREFIX:...>, $<TARGET_LINKER_FILE_BASE_NAME:...>, $<TARGET_LINKER_FILE_SUFFIX:...>, $<TARGET_PDB_FILE_BASE_NAME:...><br>
* $<TARGET_OBJECTS:...> generator expression supports executables and static, shared, and module libraries<br>
<br>
CMake 3.16 (released November 26th 2019):<br>
* Support for generator expressions in BUILD_RPATH and INSTALL_RPATH<br>
<br>
CMake 3.17 (released March 20th 2020):<br>
* Ninja Multi-Config generator, which among other things would greatly simplify LLVM_OPTIMIZED_TABLEGEN<br>
* foreach(ZIP_LISTS) added to iterate multiple lists simultaneously<br>
* New message() keywords CHECK_START, CHECK_PASS, and CHECK_FAIL<br>
* INSTALL_NAME_DIR supports generator expressions<br>
<br>
Our build system is incredibly complex, and many of these features can be used to clean it up and make it much more maintainable. I would personally like us to at least bump up to CMake 3.12. I also do think it's worth establishing a policy and process around
upgrading CMake versions, since newer versions keep on adding useful features (particularly better generator expression support), and we want to be able to keep taking advantage of them.<br>
<br>
[1] <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DNovember_136485.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=HtGj57-MndDqyK71vXRwheQXms3WKx9rT-8WAVyTB3c&e=" target="_blank">
http://lists.llvm.org/pipermail/llvm-dev/2019-November/136485.html</a> <br>
[2] <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DNovember_136488.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=hHrZYrGk0WStJ3TjjIsXg2NMvVUP-f4woTFtaFlYkG8&e=" target="_blank">
http://lists.llvm.org/pipermail/llvm-dev/2019-November/136488.html</a> <o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in">
<o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=et1KT2BvL-b2rRsPZAv8zmIauCDJSuF9FAT2IpHStVc&s=5-F9ezUsPDtcRgfY52KO7g8v-IEwwszLnGsze76Oiog&e=" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<pre style="margin-left:.5in">_______________________________________________<o:p></o:p></pre>
<pre style="margin-left:.5in">LLVM Developers mailing list<o:p></o:p></pre>
<pre style="margin-left:.5in"><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><o:p></o:p></pre>
<pre style="margin-left:.5in"><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=et1KT2BvL-b2rRsPZAv8zmIauCDJSuF9FAT2IpHStVc&s=5-F9ezUsPDtcRgfY52KO7g8v-IEwwszLnGsze76Oiog&e=" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></pre>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:.5in">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=et1KT2BvL-b2rRsPZAv8zmIauCDJSuF9FAT2IpHStVc&s=5-F9ezUsPDtcRgfY52KO7g8v-IEwwszLnGsze76Oiog&e=" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>