[llvm-dev] Upgrading LLVM's minimum required CMake version

[Petr Hosek via llvm-dev]

In the case we take availability of CMake versions in various OS
distributions into consideration, I think we need to clarify our policy
around supported distributions, for example do we only support the latest
LTS, last two, three etc. In addition, when do we deprecate support for
past versions after the release of a new version.

This makes a significant difference, e.g. Debian 9 ships 3.7.2 while Debian
10 ships 3.13.4, Ubuntu 16.04 LTS ships 3.5.1 while Ubuntu 18.04 LTS ships
3.10.2. If we only support the latest LTS, we could switch to 3.10.2 as the
minimum version, but if we wait a month, after the Ubuntu 20.04 LTS release
we could switch to 3.13.4.

On Thu, Mar 26, 2020 at 2:00 PM Roman Lebedev via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Thu, Mar 26, 2020 at 11:48 PM Nikita Popov via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > On Thu, Mar 26, 2020 at 9:07 PM Shoaib Meenai via llvm-dev <
> llvm-dev at lists.llvm.org> 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 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 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.
> >
> >
> > Thanks for the detailed analysis. Given this data, I believe the new
> CMake target should be somewhere between 3.8.0 (for which there is a strong
> motivation due to the libc++ requirement) and 3.10.2, which is the lower
> bound of what is available on current LTS distros.
> >
> > Personally, I don't think cleaning up the build system is sufficient
> motivation for a version bump that would require a non-trivial fraction of
> LLVM users to start using a custom CMake build. The build system already
> works, so there doesn't seem to be any urgent need to improve it using new
> CMake versions. If a new CMake version is needed to keep things working
> going forward (as seems to be the case for libc++), that's an entirely
> different matter, and a good motivator for bumping the version.
>
> +1
> I think bumping it up to 3.10 may fine but i'm strongly against:
> a) unconditionally bumping it just because there's a newer version
>     available (including delayed updates)
> b) considering "pull an executable from internet and run it" as
>     the proper way to update cmake
> c) not considering the versions available in debian stable/testing
>     and latest ubuntu lts as soft blockers
> d) trying to update cmake from within cmakefiles (or automatically
>     fetching stuff from internet during build in general, for that matter)
>
> > Regards,
> > Nikita
>
> Roman
>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> 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/20200326/b6597713/attachment.html>