llvm dev - Jul 2020 - Upgrading LLVM's minimum required CMake version

> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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:
> 
> 1. Immediately add a CMake warning in <root>/llvm/CMakeLists.txt
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.
> 2. Immediately send a courtesy heads-up email to all build-bot owners
telling them about the upcoming change.
> 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.
> 4. Iterate on (3) until all bots are migrated.
> 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.
> 
> Unless someone else absolutely wants to bite the bullet, I volunteer to do
the above steps.
Ok, so the thread has kept going, but AFAICT all the discussion is about a
policy for "automatic" upgrades. So I've went ahead and did the
first two steps of the above algorithm:

(1) Review at https://reviews.llvm.org/D77740
(2) Email sent to the owners of all build slaves listed on
http://lab.llvm.org:8011/buildslaves

Just to reiterate, this means that as soon as we branch LLVM 11.0.0 (the NEXT
release), CMake 3.13.4 will be the minimum required version.

Cheers,
Louis
>> On Mar 26, 2020, at 16:07, Shoaib Meenai <smeenai at fb.com
<mailto:smeenai at fb.com>> wrote:
>> 
>> 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.
>> 
>> 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.
>> 
>> 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 pkgs.org <http://pkgs.org/> for most of this
information.)
>> * RHEL 6 (released Nov 10th 2010) : 3.6.1 (via EPEL)
>> * RHEL 7 (released June 10th 2014): 3.14.7 (via EPEL)
>> * RHEL 8 (released May 7th 2019): 3.11.4 (maybe pkgs.org
<http://pkgs.org/> is screwy on this one, because it doesn’t make sense
that RHEL 7 should have a newer available version than RHEL 8)
>> * Debian 9 (released June 17th 2017): 3.7.2
>> * Debian 10 (released July 6th 2019): 3.13.4
>> * Ubuntu 16.04 LTS (released April 21st 2016): 3.5.1
>> * Ubuntu 18.04 LTS (released April 26th 2018): 3.10.2
>> * FreeBSD 11 (released October 10th 2016): 3.15.5 (presumably upgraded
in a point release)
>> * FreeBSD 12 (released December 11th 2018): 3.15.5 (presumably upgraded
in a point release)
>> * NetBSD 8.1 (released May 31st 2019): 3.16.1
>> * NetBSD 9.0 (released February 14th 2020): 3.16.1
>> * OpenBSD: couldn’t find the version
>> * macOS: latest version is readily available through Homebrew
>> * 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> CMake 3.5 (released March 8th 2016):
>> * install(DIRECTORY) supports generator expressions
>> 
>> CMake 3.6 (released July 7th 2016):
>> * install() supports EXCLUDE_FROM_ALL
>> * list() supports FILTER to filter by regular expression
>> * 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
>> * 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
>> 
>> CMake 3.7 (released November 11th 2016):
>> * New if() comparison operators LESS_EQUAL, GREATER_EQUAL,
STRLESS_EQUAL, STRGREATER_EQUAL, VERSION_LESS_EQUAL, and VERSION_GREATER_EQUAL
>> 
>> CMake 3.8 (released April 10th 2017):
>> * Compile features for C++17, which is required to build libc++
correctly
>> * Support for compile features for specific C++ features instead of
only being able to specify standard versions
>> * rpath support via BUILD_RPATH target property and CMAKE_BUILD_RPATH
variable
>> * Apple framework support for static libraries
>> * New swig_add_library command in the UseSWIG module
>> * New generator expression $<IF:cond,true-value,false-value>
>> 
>> CMake 3.9 (released July 18th 2017):
>> * install(TARGETS) and install(EXPORTS) support for object libraries,
which will simplify the compiler-rt build
>> * TARGET_OBJECTS generator expression support in add_custom_command and
file(GENERATE)
>> * $<TARGET_BUNDLE_DIR:tgt> and
$<TARGET_BUNDLE_CONTENT_DIR:tgt> generator expressions for Apple bundles
>> 
>> CMake 3.10 (released November 20th 2017):
>> * include_guard() command for proper guarding against double includes
of CMake scripts
>> * 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
>> 
>> CMake 3.11 (released March 28th 2018):
>> * add_library() and add_executable() can be called without sources as
long as target_sources() is used later
>> * target_compile_{definitions,features,options},
target_include_directories(), target_sources(), and target_link_libraries() can
set the corresponding INTERFACE_* properties on imported targets
>> * COMPILE_DEFINITIONS supports generator expressions
>> * COMPILE_OPTIONS source file property added
>> * INCLUDE_DIRECTORIES source file property added
>> * Interface libraries support custom properites
>> 
>> CMake 3.12 (released July 17th 2018):
>> * add_compile_definitions() added to add compile definitions for
targets (to avoid the global pollution caused by add_definitions())
>> * cmake_minimum_required() supports a version range to indicate tested
CMake versions and set policies accordingly
>> * file(TOUCH) and file(TOUCH_NOCREATE) added
>> * list(JOIN), list(SUBLIST) and list(TRANSFORM) added
>> * string(JOIN) added
>> * SHELL: prefix support in target_compile_options to avoid errant
deduplication
>> * target_link_libraries() supports object libraries and propagates
usage requirements
>> * EXPORT_PROPERTIES target property to control the target properties
exported by export() and install(EXPORT)
>> * FindLibXml2 provides imported targets
>> * New FindPython, FindPython2, and FindPython3 modules to ease location
Python and selecting a specific version
>> * Modernization of UseSWIG module
>> * New generator expressions $<GENEX_EVAL:...>,
$<TARGET_GENEX_EVAL:target,...>, $<IN_LIST:...>,
$<TARGET_EXISTS:...> and $<TARGET_NAME_IF_EXISTS:...>
>> * Compile features support for C++20
>> 
>> CMake 3.13 (released November 20th 2018):
>> * cmake -E create_symlink supported on Windows
>> * target_link_directories() and target_link_options() commands to set
link options instead of awkwardly having to use target_link_libraries() for this
purpose
>> * UseSWIG can manage INCLUDE_DIRECTORIES for SWIG compilation
>> 
>> CMake 3.14 (released March 14th 2019):
>> * file(CREATE_LINK) to create hard or symbolic links
>> * if(DEFINED CACHE{VAR}) for checking if a cache variable is defined
>> * $<IN_LIST:...> generator expression correctly handles empty
argument
>> * Fixes for object library linking propagation
>> * Link options to manage position independent executables added
automatically
>> 
>> CMake 3.15 (released July 17th 2019):
>> * list(PREPEND), list(POP_FRONT) and list(POP_BACK) added
>> * New message() types NOTICE, VERBOSE, DEBUG and TRACE
>> * string(REPEAT) added
>> * MSVC_RUNTIME_LIBRARY target property and CMAKE_MSVC_RUNTIME_LIBRARY
variable to select the runtime library type for MSVC
>> * $<C_COMPILER_ID:...>, $<CXX_COMPILER_ID:...>,
$<COMPILE_LANGUAGE:...>, and $<PLATFORM_ID:...> generator
expressions support matching one value from a list
>> * $<COMPILE_LANG_AND_ID:...> generator expression added
>> * $<FILTER:list,INCLUDE|EXCLUDE,regex> generator expression added
>> * $<REMOVE_DUPLICATES:list> generator expression added
>> * 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:...>
>> * $<TARGET_OBJECTS:...> generator expression supports executables
and static, shared, and module libraries
>> 
>> CMake 3.16 (released November 26th 2019):
>> * Support for generator expressions in BUILD_RPATH and INSTALL_RPATH
>> 
>> CMake 3.17 (released March 20th 2020):
>> * Ninja Multi-Config generator, which among other things would greatly
simplify LLVM_OPTIMIZED_TABLEGEN
>> * foreach(ZIP_LISTS) added to iterate multiple lists simultaneously
>> * New message() keywords CHECK_START, CHECK_PASS, and CHECK_FAIL
>> * INSTALL_NAME_DIR supports generator expressions
>> 
>> 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.
>> 
>> [1] http://lists.llvm.org/pipermail/llvm-dev/2019-November/136485.html
<http://lists.llvm.org/pipermail/llvm-dev/2019-November/136485.html>
>> [2] http://lists.llvm.org/pipermail/llvm-dev/2019-November/136488.html
<http://lists.llvm.org/pipermail/llvm-dev/2019-November/136488.html>
>> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200408/9897189d/attachment.html>

> On Apr 8, 2020, at 13:06, Louis Dionne <ldionne at apple.com> wrote:
> 
> 
>> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> 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:
>> 
>> 1. Immediately add a CMake warning in <root>/llvm/CMakeLists.txt
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.
>> 2. Immediately send a courtesy heads-up email to all build-bot owners
telling them about the upcoming change.
>> 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.
>> 4. Iterate on (3) until all bots are migrated.
>> 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.
>> 
>> Unless someone else absolutely wants to bite the bullet, I volunteer to
do the above steps.
> 
> Ok, so the thread has kept going, but AFAICT all the discussion is about a
policy for "automatic" upgrades. So I've went ahead and did the
first two steps of the above algorithm:
> 
> (1) Review at https://reviews.llvm.org/D77740
<https://reviews.llvm.org/D77740>
> (2) Email sent to the owners of all build slaves listed on
http://lab.llvm.org:8011/buildslaves
<http://lab.llvm.org:8011/buildslaves>
> 
> Just to reiterate, this means that as soon as we branch LLVM 11.0.0 (the
NEXT release), CMake 3.13.4 will be the minimum required version.
Hi,

Just a heads up that about two weeks from now, we should be branching for the
LLVM 11.0.0 release. Right after we branch, I will implement steps (3) and (4)
of the algorithm described above, which is to make the minimum CMake version
required be 3.13.4. I will do this by checking-in this patch:
https://reviews.llvm.org/D78646 <https://reviews.llvm.org/D78646>.

That patch will cause errors whenever the CMake version is less than 3.13.4 -- I
will then revert and re-apply this patch until all build bots have upgraded to a
sufficient CMake. The patch was crafted to be minimal and revert-friendly. Note
that build bot owners have already been contacted in March and pinged several
times again for those who had not yet upgraded. At this time, I think only 1-2
bots have not upgraded.

Once everyone has upgraded, I will then apply this patch:
https://reviews.llvm.org/D78648 <https://reviews.llvm.org/D78648>. That
patch marks the minimum CMake version required as being 3.13.4 throughout the
monorepo in a slightly more invasive but definitive way. Once that's all
done, I'll report to the list that the version bump is complete and we can
all start using modern CMake features.

Cheers,
Louis
> 
> Cheers,
> Louis
> 
>>> On Mar 26, 2020, at 16:07, Shoaib Meenai <smeenai at fb.com
<mailto:smeenai at fb.com>> wrote:
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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 pkgs.org <http://pkgs.org/> for most of this
information.)
>>> * RHEL 6 (released Nov 10th 2010) : 3.6.1 (via EPEL)
>>> * RHEL 7 (released June 10th 2014): 3.14.7 (via EPEL)
>>> * RHEL 8 (released May 7th 2019): 3.11.4 (maybe pkgs.org
<http://pkgs.org/> is screwy on this one, because it doesn’t make sense
that RHEL 7 should have a newer available version than RHEL 8)
>>> * Debian 9 (released June 17th 2017): 3.7.2
>>> * Debian 10 (released July 6th 2019): 3.13.4
>>> * Ubuntu 16.04 LTS (released April 21st 2016): 3.5.1
>>> * Ubuntu 18.04 LTS (released April 26th 2018): 3.10.2
>>> * FreeBSD 11 (released October 10th 2016): 3.15.5 (presumably
upgraded in a point release)
>>> * FreeBSD 12 (released December 11th 2018): 3.15.5 (presumably
upgraded in a point release)
>>> * NetBSD 8.1 (released May 31st 2019): 3.16.1
>>> * NetBSD 9.0 (released February 14th 2020): 3.16.1
>>> * OpenBSD: couldn’t find the version
>>> * macOS: latest version is readily available through Homebrew
>>> * 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> CMake 3.5 (released March 8th 2016):
>>> * install(DIRECTORY) supports generator expressions
>>> 
>>> CMake 3.6 (released July 7th 2016):
>>> * install() supports EXCLUDE_FROM_ALL
>>> * list() supports FILTER to filter by regular expression
>>> * 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
>>> * 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
>>> 
>>> CMake 3.7 (released November 11th 2016):
>>> * New if() comparison operators LESS_EQUAL, GREATER_EQUAL,
STRLESS_EQUAL, STRGREATER_EQUAL, VERSION_LESS_EQUAL, and VERSION_GREATER_EQUAL
>>> 
>>> CMake 3.8 (released April 10th 2017):
>>> * Compile features for C++17, which is required to build libc++
correctly
>>> * Support for compile features for specific C++ features instead of
only being able to specify standard versions
>>> * rpath support via BUILD_RPATH target property and
CMAKE_BUILD_RPATH variable
>>> * Apple framework support for static libraries
>>> * New swig_add_library command in the UseSWIG module
>>> * New generator expression $<IF:cond,true-value,false-value>
>>> 
>>> CMake 3.9 (released July 18th 2017):
>>> * install(TARGETS) and install(EXPORTS) support for object
libraries, which will simplify the compiler-rt build
>>> * TARGET_OBJECTS generator expression support in add_custom_command
and file(GENERATE)
>>> * $<TARGET_BUNDLE_DIR:tgt> and
$<TARGET_BUNDLE_CONTENT_DIR:tgt> generator expressions for Apple bundles
>>> 
>>> CMake 3.10 (released November 20th 2017):
>>> * include_guard() command for proper guarding against double
includes of CMake scripts
>>> * 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
>>> 
>>> CMake 3.11 (released March 28th 2018):
>>> * add_library() and add_executable() can be called without sources
as long as target_sources() is used later
>>> * target_compile_{definitions,features,options},
target_include_directories(), target_sources(), and target_link_libraries() can
set the corresponding INTERFACE_* properties on imported targets
>>> * COMPILE_DEFINITIONS supports generator expressions
>>> * COMPILE_OPTIONS source file property added
>>> * INCLUDE_DIRECTORIES source file property added
>>> * Interface libraries support custom properites
>>> 
>>> CMake 3.12 (released July 17th 2018):
>>> * add_compile_definitions() added to add compile definitions for
targets (to avoid the global pollution caused by add_definitions())
>>> * cmake_minimum_required() supports a version range to indicate
tested CMake versions and set policies accordingly
>>> * file(TOUCH) and file(TOUCH_NOCREATE) added
>>> * list(JOIN), list(SUBLIST) and list(TRANSFORM) added
>>> * string(JOIN) added
>>> * SHELL: prefix support in target_compile_options to avoid errant
deduplication
>>> * target_link_libraries() supports object libraries and propagates
usage requirements
>>> * EXPORT_PROPERTIES target property to control the target
properties exported by export() and install(EXPORT)
>>> * FindLibXml2 provides imported targets
>>> * New FindPython, FindPython2, and FindPython3 modules to ease
location Python and selecting a specific version
>>> * Modernization of UseSWIG module
>>> * New generator expressions $<GENEX_EVAL:...>,
$<TARGET_GENEX_EVAL:target,...>, $<IN_LIST:...>,
$<TARGET_EXISTS:...> and $<TARGET_NAME_IF_EXISTS:...>
>>> * Compile features support for C++20
>>> 
>>> CMake 3.13 (released November 20th 2018):
>>> * cmake -E create_symlink supported on Windows
>>> * target_link_directories() and target_link_options() commands to
set link options instead of awkwardly having to use target_link_libraries() for
this purpose
>>> * UseSWIG can manage INCLUDE_DIRECTORIES for SWIG compilation
>>> 
>>> CMake 3.14 (released March 14th 2019):
>>> * file(CREATE_LINK) to create hard or symbolic links
>>> * if(DEFINED CACHE{VAR}) for checking if a cache variable is
defined
>>> * $<IN_LIST:...> generator expression correctly handles empty
argument
>>> * Fixes for object library linking propagation
>>> * Link options to manage position independent executables added
automatically
>>> 
>>> CMake 3.15 (released July 17th 2019):
>>> * list(PREPEND), list(POP_FRONT) and list(POP_BACK) added
>>> * New message() types NOTICE, VERBOSE, DEBUG and TRACE
>>> * string(REPEAT) added
>>> * MSVC_RUNTIME_LIBRARY target property and
CMAKE_MSVC_RUNTIME_LIBRARY variable to select the runtime library type for MSVC
>>> * $<C_COMPILER_ID:...>, $<CXX_COMPILER_ID:...>,
$<COMPILE_LANGUAGE:...>, and $<PLATFORM_ID:...> generator
expressions support matching one value from a list
>>> * $<COMPILE_LANG_AND_ID:...> generator expression added
>>> * $<FILTER:list,INCLUDE|EXCLUDE,regex> generator expression
added
>>> * $<REMOVE_DUPLICATES:list> generator expression added
>>> * 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:...>
>>> * $<TARGET_OBJECTS:...> generator expression supports
executables and static, shared, and module libraries
>>> 
>>> CMake 3.16 (released November 26th 2019):
>>> * Support for generator expressions in BUILD_RPATH and
INSTALL_RPATH
>>> 
>>> CMake 3.17 (released March 20th 2020):
>>> * Ninja Multi-Config generator, which among other things would
greatly simplify LLVM_OPTIMIZED_TABLEGEN
>>> * foreach(ZIP_LISTS) added to iterate multiple lists simultaneously
>>> * New message() keywords CHECK_START, CHECK_PASS, and CHECK_FAIL
>>> * INSTALL_NAME_DIR supports generator expressions
>>> 
>>> 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.
>>> 
>>> [1]
http://lists.llvm.org/pipermail/llvm-dev/2019-November/136485.html
<http://lists.llvm.org/pipermail/llvm-dev/2019-November/136485.html>
>>> [2]
http://lists.llvm.org/pipermail/llvm-dev/2019-November/136488.html
<http://lists.llvm.org/pipermail/llvm-dev/2019-November/136488.html>
>>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/0ff8f748/attachment.html>

On 30 Jun 2020, at 16:04, Louis Dionne via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> On Apr 8, 2020, at 13:06, Louis Dionne <ldionne at apple.com>
wrote:
>>> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>> 
>>> 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:
>>> 
>>> 1. Immediately add a CMake warning in
<root>/llvm/CMakeLists.txt 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.
>>> 2. Immediately send a courtesy heads-up email to all build-bot
owners telling them about the upcoming change.
>>> 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.
>>> 4. Iterate on (3) until all bots are migrated.
>>> 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.
>>> 
>>> Unless someone else absolutely wants to bite the bullet, I
volunteer to do the above steps.
>> 
>> Ok, so the thread has kept going, but AFAICT all the discussion is
about a policy for "automatic" upgrades. So I've went ahead and
did the first two steps of the above algorithm:
>> 
>> (1) Review at https://reviews.llvm.org/D77740
>> (2) Email sent to the owners of all build slaves listed on
http://lab.llvm.org:8011/buildslaves
>> 
>> Just to reiterate, this means that as soon as we branch LLVM 11.0.0
(the NEXT release), CMake 3.13.4 will be the minimum required version.
> 
> Hi,
> 
> Just a heads up that about two weeks from now, we should be branching for
the LLVM 11.0.0 release. Right after we branch, I will implement steps (3) and
(4) of the algorithm described above, which is to make the minimum CMake version
required be 3.13.4. I will do this by checking-in this patch:
https://reviews.llvm.org/D78646.
> 
> That patch will cause errors whenever the CMake version is less than 3.13.4
-- I will then revert and re-apply this patch until all build bots have upgraded
to a sufficient CMake. The patch was crafted to be minimal and revert-friendly.
Note that build bot owners have already been contacted in March and pinged
several times again for those who had not yet upgraded. At this time, I think
only 1-2 bots have not upgraded.
> 
> Once everyone has upgraded, I will then apply this patch:
https://reviews.llvm.org/D78648. That patch marks the minimum CMake version
required as being 3.13.4 throughout the monorepo in a slightly more invasive but
definitive way. Once that's all done, I'll report to the list that the
version bump is complete and we can all start using modern CMake features.
> 
> Cheers,
> Louis
I missed this entire discussion but would like to chime in. All of our
department's machines run on Ubuntu 18.04 as standard. I suspect the same is
true across a large number of organisations, as Ubuntu is a very popular
distribution, and the 18.04 LTS is still widely supported by most projects.
Whilst Ubuntu 20.04 has been released for a couple of months, it's going to
be a while until everyone has updated. In fact, it isn't yet *officially
supported* to upgrade from 18.04 to 20.04, as you have to wait for the first
point release for that, due in August. So as far as Canonical are concerned, if
you installed 18.04 LTS, you should still be on that, and 20.04 isn't ready
for those people quite yet. That's a lot of people affected who may not be
following llvm-dev but will suddenly find themselves in need of a custom CMake.

I would urge people to reconsider this move. I can see the attraction of moving
to the latest CMake, but we've managed just fine so far, do we really need
to move to the latest and greatest right now? Ditching support for 18.04 in a
year's time would seem reasonable, but expecting everyone to have moved over
when it's not yet officially supported after just 3 months is not, and
forcing everyone on those distributions to build their own copy of CMake just
for LLVM is annoying (sure, I'm perfectly capable of doing it, but it's
still a nuisance that aggravates me). I'd suggest waiting at least until
20.04.1 has been released, so waiting until the next release cycle would allow
that and give around 6 months for people to update, if not until the release
cycle after that (though that may be a harder pill for some members to swallow).
But we could at least bump to 3.10.2 in the meantime.

Jess

> On Jun 30, 2020, at 11:04, Louis Dionne via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
>> On Apr 8, 2020, at 13:06, Louis Dionne <ldionne at apple.com
<mailto:ldionne at apple.com>> wrote:
>> 
>> 
>>> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 
>>> 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:
>>> 
>>> 1. Immediately add a CMake warning in
<root>/llvm/CMakeLists.txt 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.
>>> 2. Immediately send a courtesy heads-up email to all build-bot
owners telling them about the upcoming change.
>>> 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.
>>> 4. Iterate on (3) until all bots are migrated.
>>> 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.
>>> 
>>> Unless someone else absolutely wants to bite the bullet, I
volunteer to do the above steps.
>> 
>> Ok, so the thread has kept going, but AFAICT all the discussion is
about a policy for "automatic" upgrades. So I've went ahead and
did the first two steps of the above algorithm:
>> 
>> (1) Review at https://reviews.llvm.org/D77740
<https://reviews.llvm.org/D77740>
>> (2) Email sent to the owners of all build slaves listed on
http://lab.llvm.org:8011/buildslaves
<http://lab.llvm.org:8011/buildslaves>
>> 
>> Just to reiterate, this means that as soon as we branch LLVM 11.0.0
(the NEXT release), CMake 3.13.4 will be the minimum required version.
> 
> Hi,
> 
> Just a heads up that about two weeks from now, we should be branching for
the LLVM 11.0.0 release. Right after we branch, I will implement steps (3) and
(4) of the algorithm described above, which is to make the minimum CMake version
required be 3.13.4. I will do this by checking-in this patch:
https://reviews.llvm.org/D78646 <https://reviews.llvm.org/D78646>.
> 
> That patch will cause errors whenever the CMake version is less than 3.13.4
-- I will then revert and re-apply this patch until all build bots have upgraded
to a sufficient CMake. The patch was crafted to be minimal and revert-friendly.
Note that build bot owners have already been contacted in March and pinged
several times again for those who had not yet upgraded. At this time, I think
only 1-2 bots have not upgraded.
> 
> Once everyone has upgraded, I will then apply this patch:
https://reviews.llvm.org/D78648 <https://reviews.llvm.org/D78648>. That
patch marks the minimum CMake version required as being 3.13.4 throughout the
monorepo in a slightly more invasive but definitive way. Once that's all
done, I'll report to the list that the version bump is complete and we can
all start using modern CMake features.
Hi,

I completed steps (3) and (4) of the above upgrade path last week without
issues. I waited a couple of days to make sure nothing new came up, and just now
I pushed the last patch that performs the upgrade.

So.. we're now allowed to use CMake 3.13.4 features in the code! Enjoy.

Thanks to everybody who collaborated,
Louis

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200722/cafe3e01/attachment.html>