[llvm-dev] Upgrading LLVM's minimum required CMake version
Petr Hosek via llvm-dev
llvm-dev at lists.llvm.org
Thu Mar 26 15:13:29 PDT 2020
Do you think that Kitware would be willing to provide packages for Debian 9
and 10 as well if we ask them?
On Thu, Mar 26, 2020 at 2:48 PM Shoaib Meenai via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> What do you think of third-party APT repositories? CMake has one for
> acquiring newer CMake versions on Ubuntu 16.04 and 18.04:
> https://apt.kitware.com/
>
> On 3/26/20, 2:00 PM, "Roman Lebedev" <lebedev.ri at gmail.com> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=5p-e5UINQFuSo4ra3nIJCayYP7-BYuTLfwNiqfBpAP0&s=aPzCoTKfHEsLemfcpxKGsRMpFbLEIPGxqX8J6UHfI-o&e=
>
>
> _______________________________________________
> 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/50415f0a/attachment-0001.html>
More information about the llvm-dev
mailing list