<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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 class="moz-txt-link-freetext" href="https://packages.ubuntu.com/">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>
<p><font size="-1">The difference between installing or building
Clang and LLVM from original sources as against installing
versions available from the distribution 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>
<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>
<p><font size="-1">Neil Nelson<br>
</font></p>
<div class="moz-cite-prefix"><font size="-1">On 4/4/20 11:48 AM,
Mehdi AMINI via llvm-dev wrote:<br>
</font></div>
<blockquote type="cite"
cite="mid:CANF-O=Z9fUGpiavPLYwBRVAbyS6_OPKhmLbm2aeaSWL-Ndr94g@mail.gmail.com"><font
size="-1">
</font>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 2, 2020 at 10:49
AM Shoaib Meenai 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 lang="EN-US">
<div class="gmail-m_-7367194822588477337WordSection1">
<p class="MsoNormal">I’m in favor of all this. Thanks
for volunteering! I’m happy to help out in whatever
way.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Some things it might be worth
figuring out for future upgrades:</p>
<p class="MsoNormal">* 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)?</p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Can you clarify what "supported" means? Does it include
PPA on ubuntu for example?</div>
<div>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.</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 lang="EN-US">
<div class="gmail-m_-7367194822588477337WordSection1">
<p class="MsoNormal">* 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?</p>
<p class="MsoNormal">* 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?</p>
<p class="MsoNormal"> </p>
<div style="border-style:solid none
none;border-top-width:1pt;border-top-color:rgb(181,196,223);padding:3pt
0in 0in">
<p class="MsoNormal" style="margin-left:0.5in"><b><span
style="font-size:12pt;color:black">From:
</span></b><span
style="font-size:12pt;color:black"><<a
href="mailto:ldionne@apple.com" target="_blank"
moz-do-not-send="true">ldionne@apple.com</a>>
on behalf of Louis Dionne <<a
href="mailto:ldionne@apple.com" target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">smeenai@fb.com</a>><br>
<b>Cc: </b>"<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>"
<<a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>,
Chris Bieneman <<a
href="mailto:beanz@apple.com" target="_blank"
moz-do-not-send="true">beanz@apple.com</a>>,
Petr Hosek <<a
href="mailto:phosek@chromium.org"
target="_blank" moz-do-not-send="true">phosek@chromium.org</a>>,
Saleem Abdulrasool <<a
href="mailto:compnerd@compnerd.org"
target="_blank" moz-do-not-send="true">compnerd@compnerd.org</a>>,
"<a href="mailto:tstellar@redhat.com"
target="_blank" moz-do-not-send="true">tstellar@redhat.com</a>"
<<a href="mailto:tstellar@redhat.com"
target="_blank" moz-do-not-send="true">tstellar@redhat.com</a>><br>
<b>Subject: </b>Re: Upgrading LLVM's minimum
required CMake version</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<p class="MsoNormal" style="margin-left:0.5in">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:
</p>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">1.
Immediately add a CMake warning in
<span style="font-family:Monaco"><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.</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">2.
Immediately send a courtesy heads-up email to all
build-bot owners telling them about the upcoming
change.</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">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.</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">4.
Iterate on (3) until all bots are migrated.</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">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.</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Unless
someone else absolutely wants to bite the bullet, I
volunteer to do the above steps.</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Thoughts?</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Louis</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<div>
<div>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal" style="margin-left:0.5in">On
Mar 26, 2020, at 16:07, Shoaib Meenai <<a
href="mailto:smeenai@fb.com"
target="_blank" moz-do-not-send="true">smeenai@fb.com</a>>
wrote:</p>
</div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
<div>
<div>
<p class="MsoNormal"
style="margin-right:0in;margin-bottom:12pt;margin-left:0.5in">
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" moz-do-not-send="true">
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" moz-do-not-send="true">
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" moz-do-not-send="true">
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" moz-do-not-send="true">
http://lists.llvm.org/pipermail/llvm-dev/2019-November/136488.html</a> </p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</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>