"friendlyanon" wrote:

Considering how much of Boost is header-only libraries, I recommend sticking to 3.14 across the board at a very minimum to be able to use the ARCH_INDEPENDENT argument for CMake package generation.

BoostInstall already takes care of that. It's not a feature worth killing the entire build for, especially since installation is (kind of) optional. Although since installation needs 3.13 anyway, going to 3.14 instead makes sense - _if_ we decided to go with 3.13.

On 02/06/2021 19:07, Peter Dimov via Boost wrote:

Niall Douglas wrote:

...

- RHEL7 ships with cmake 3.9

CentOS 7 ships with 2.8. But fortunately, you can install `cmake3` from EPEL, which is 3.17.

Ah yes. My workplace is on an older CentOS 7. Sigh.

I haven't investigated how well `pip install --user cmake` works on those distros; it works on Travis, at least, and typically gives me the latest version. Of course non-x86 platforms might have a different experience.

CentOS 7 is still python 2 based? I ask because I can see pip install cmake stopping working at some point when they kill pip working with python 2. I'm seeing lots of votes for really recent cmakes, which I don't understand the reasoning for other than "let's use the newest cmake just cos". I also think there is an undervaluing here of forcing end users to go off an install a newer cmake. For a whole bunch of corporate devs, they're not allowed root access, to get newer tooling installed over platform default is sufficient admin hassle that they'd rather forgo upgrading the software they are using. It is for this exact same reason they don't use any Boost library which isn't header only, and I wouldn't want to add to that. Also, on some CentOS/RHEL/Docker systems, the local cmake is specially configured for that system, and compiling your own or using the prebuilt cmake binaries they won't work without non-obvious customised build options. I say this from painful experience: making people use a non-default cmake is a real turn off. For me, if there is a *compelling* reason to use a newer cmake, then I'm all for it. I'm not aware of any *compelling* feature adds after cmake 3.8, they're all nice to haves, not must haves. Even find_dependency() is hardly a showstopper, you can hand craft an emulation wrapping find_package() without much effort. Meanwhile, Ubuntu 18.04 LTS which is cmake 3.9 will be very popular until 2023, and not fall out of usage until 2028. All the Ubuntu servers I'm running, and all those at work, they're ALL 18.04 and I don't expect that to change until 2023 or so when we'll jump to 22.04 LTS because we tend to track every second Ubuntu LTS release. We are hardly unusual in this, if anything, we are much less conservative than most of our big corporate work clients who are only *just now* upgrading from RHEL6 to RHEL7. So I'd like to reiterate my recommendation that we choose cmake 3.8 or 3.9, then Boost cmake is widely usable straight out of the box for big corporate users. What do we lose by standardising on an older cmake version? Niall

Le mercredi 02 juin 2021 à 22:23 +0300, Andrey Semashev via Boost a écrit :

Debian Stretch: 3.7.2 Debian Buster: 3.13.4

I'll add Debian Bullseye : 3.18.4. Stretch is already oldstable, and with the release of bullseye in the upcoming months, stretch is gonna be eol soon. Not sure if it's worth supporting. Regards, Julien

Alexander Grund wrote:

...

- CMake 3.9: required by Nowide, I'm not sure why. ... I use find_dependency there which requires 3.9.

find_dependency doesn't require 3.9, but passing it arbitrary arguments does. Before 3.9 it only accepts a version. https://cmake.org/cmake/help/v3.5/module/CMakeFindDependencyMacro.html https://cmake.org/cmake/help/v3.9/module/CMakeFindDependencyMacro.html Your use in Nowide should work on 3.5.

Alexander Grund wrote:

...

...

- CMake 3.9: required by Nowide, I'm not sure why. ... I use find_dependency there which requires 3.9.

find_dependency doesn't require 3.9, but passing it arbitrary arguments does. Before 3.9 it only accepts a version.

https://cmake.org/cmake/help/v3.5/module/CMakeFindDependencyMacro.h tml https://cmake.org/cmake/help/v3.9/module/CMakeFindDependencyMacro.h tml

Your use in Nowide should work on 3.5.

Oh, by the way, the find_dependency line in the config file is executed when the installed library is used by find_package, which is done by a different cmake, so requiring the current version to be 3.9 doesn't help, you still need to guard it if you use e.g. COMPONENTS.

On 6/3/21 11:03 AM, Paul A Bristow via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Peter Dimov via Boost Sent: 2 June 2021 17:32 To: boost@lists.boost.org Cc: Peter Dimov Subject: [boost] CMake minimum version to support

I suppose the time has come to have the discussion on the minimum CMake version we will support for building Boost. Currently that's set to 3.5, which kind of works, but is fairly inconvenient.

The interesting options are

- CMake 3.8: required for use of the compile features cxx_std_11, cxx_std_14, cxx_std_17, etc. Also allows source_group(TREE, which is used by Json and PropertyTree.

- CMake 3.9: required by Nowide, I'm not sure why. Also, required for FindMPI to define an imported target. Building Boost.MPI is optional though.

- CMake 3.13: required for Boost installation support.

- CMake 3.14: required for FindPython to be modern enough to make building Boost.Python reasonably easy. (Building Boost.Python is optional, though.)

There are also less important nice-to-have things such as

- CMake 3.10: adds include_guard() - CMake 3.12: adds CONFIGURE_DEPENDS to file(GLOB - CMake 3.15: adds VERBOSE/DEBUG to message(

Opinions?

Assuming that installing/updating Cmake is easy, I would suggest that we fix the Cmake requirement at the most recent version of CMake released at the time of the Boost release date.

Upgrading a package in a Linux distro outside a package repository is not as easy. I mean, yes, you could do it Windows way and just unzip an archive with a new version somewhere in the system and use it, but this is not the recommended thing to do as the system becomes unmaintainable and broken over time. You want a package built for your distro, and uploaded in a repository so that users are able to keep their systems updated. And the repository has to be trusted (i.e. preferably, from the distro maintainers). The last point is especially important for build and developer machines. This is why on distros with periodic release model the software does not get installed from anywhere but the distro repositories, and you may be locked to particular versions until you upgrade to the next distro release.

Including instructions on how to update CMake for popular platforms in the Boost 'how-to-install' instructions would be really helpful - and fend off moaners.

That is a simple enduring policy and needs no discussion (like this one) on each release.

This matches what we do for b2 - always rebuild for each Boost release.

KISS!

Paul

PS I assume there are no 'backward compatibility' issues with enforcing a CMake update.

Actually, there are. CMake does make backward incompatible changes from time to time. It usually provides config options to choose the old or new behavior, but those are intended as a transition means and are removed after some time. It is possible that different projects on the system might require different behaviors, and if CMake is ungraded to a version that removes the compatibility knob, some projects may become unbuildable.

Am 03.06.21 um 13:25 schrieb Rainer Deyke via Boost:

... CMake requires GNU Make plus a whole bunch of development libraries.

This is not entirely correct. In order to build CMake you need, besides a C++11 compiler, some "make" tool, which can be GNU Make but could also be Ninja or some other make tool (possibly the one coming with Visual Studio). And one of these you will need anyway (as generator) if your wish to build Boost with CMake. The "bunch of development libraries" that CMake requires for building (curl, expat, zlib ...) can be used from the OS, but by default CMake uses the ones it brings itself. Therefore, building (and installing) CMake locally without the need for root access should be possible without any problem. Deniz -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir@benocs.com www.benocs.com Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

Am 03.06.21 um 13:55 schrieb Mike via Boost:

...

Gesendet: Mittwoch, 02. Juni 2021 um 18:32 Uhr Von: "Peter Dimov via Boost"

I suppose the time has come to have the discussion on the minimum CMake version we will support for building Boost. Currently that's set to 3.5, which kind of works, but is fairly inconvenient.

The interesting options are

- CMake 3.8: required for use of the compile features cxx_std_11, cxx_std_14, cxx_std_17, etc. Also allows source_group(TREE, which is used by Json and PropertyTree.

- CMake 3.9: required by Nowide, I'm not sure why. Also, required for FindMPI to define an imported target. Building Boost.MPI is optional though.

- CMake 3.13: required for Boost installation support.

- CMake 3.14: required for FindPython to be modern enough to make building Boost.Python reasonably easy. (Building Boost.Python is optional, though.)

There are also less important nice-to-have things such as

- CMake 3.10: adds include_guard() - CMake 3.12: adds CONFIGURE_DEPENDS to file(GLOB - CMake 3.15: adds VERBOSE/DEBUG to message(

Opinions? If it were me. I'd pick a rather high minimal version initially that will give maximum convenience/power for implementing current and future features and then see if there is significant demand from the community to support older versions.

- Due to lack of usage statistics or knowledge about future requirements/feature requests, no one will be able to find the "optimal" tradeoff anyway. So design for change!

- Tis will be a new (at least officially) and optional feature of boost so there aren't any existing users that are being broken - Backporting any functionality to older versions or adding partial support for older versions if that should become necessary, is much less disruptive for the user base than increasing the minimal version later on.

This sounds like a great advice. Especially, as it is now possible to provide a range of CMake versions in the `cmake_minimum_required` command that are explicitly supported. (That was introduced in CMake 3.12, but even older CMake version work when they encounter it. They just use the oldest version from that range.) Assuming Boost would choose the latest currently available CMake version (3.20), whether it requires any specific feature/behavior introduced by it or not, one still could then later add an older version to the supported (and tested) range if required, as Mike wrote. Of course, adding older versions to the list of supported CMake versions might probably require some adjustments to the CMakeLists.txt files. These could be introduced conditionally (with `if (POLICY CMP...)` or `if (CMAKE_VERSION LESS ${CMAKE_VERSION})`) and e.g. skip some newer, helpful and easier CMake commands/features and use some workaround for these old CMake versions. This should also help deciding if it is really worth to support such an old CMake version if it means to re-introduce too many old quirks. On the other hand, dropping support for such an old version again, just means to remove these workarounds again and to adjust the version range in the `cmake_minimum_required` command accordingly. And dropping or not adding support for old CMake versions should be fine because it will still be possible to build Boost with b2 (which is still part of every Boost release).

- It is reasonable to expect (but not necessarily true) that the users that are using very old linux distributions are not going to be the majority of early adopters of cmake-based builds anyway - Updating cmake is really easy - even on linux. Of course there might be policy reasons not to do it ("we only use what comes from the official repositories"), but almost any argument I've heard against upgrading cmake is also a valid argument against upgrading boost. - Just as with compiler versions, fewer supported cmake versions simply means less maintenence and test effort as well as less workarounds, even if no significant features are missing. - History shows that getting consensu to dropp support for anything (e.g. older cmake versions in this case) is very likely going to be a pain in the .... So it is reasonable to assume that whatever is picked now will still be the en force many years from now when linux distributions have long progressed Hence it would make sense to err on the side of being too modern and fix it if its really necessary, than being too permissive now based on speculation of what users might want and being stuck with those restrictions.

My vote would be 3.13 (Debian stable - soon old stable), or even 3.15 which also adds the MSVC_RUNTIME_LIBRARY setting and is supported by the recent

Btw.: AFAIK, Visual studio 2019 currently shipps with cmake 3.20, but I don't know, where to look up historic versions. It might be valuable to check if other IDEs also have integrated cmake and what version that is.

Mike

I totally support what Mike just wrote. I would just choose the latest available CMake version (3.20) as the starting point and see how it goes from there. Deniz -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir@benocs.com www.benocs.com Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

On 6/3/21 5:06 PM, Deniz Bahadir via Boost wrote:

I totally support what Mike just wrote. I would just choose the latest available CMake version (3.20) as the starting point and see how it goes from there.

I have to say that if we choose the latest CMake version as the minimum, this would be unmaintainable for me. I won't be installing non-standard CMake versions on my development machines. This would also be problematic for CI. I think, there doesn't have to be a single minimum version to mandate. This is a question each library maintainer can answer himself. I, for one, don't need anything above 3.5 in the libraries I currently maintain, possibly even less than that. If I had to pick a reasonable threshold version for my libraries, based on the CMake versions available in various distros that I listed earlier, it seems somewhere around 3.9-3.10 would still maintain reasonable compatibility while being relatively recent. But I think the real question Peter is asking is what minimum version Boost superproject and common CMake scripts should require. My preference would be as low as possible, definitely not the latest, as suggested by some. But I don't know about the superproject or CMake enough to require anything; I don't know what CMake features would be important there. It looks like Peter, as the main (only?) maintainer of those scripts, has the best knowledge to make that decision.

Gesendet: Donnerstag, 03. Juni 2021 um 16:06 Uhr Von: "Deniz Bahadir via Boost"

I totally support what Mike just wrote. I would just choose the latest available CMake version (3.20) as the starting point and see how it goes from there.

Just to be clear, I said I'd pick a relatively high version (e.g. 3.13 or 3.15). I did not recommend to pick the latest version (3.20 / 3.21?). Mike

Mike wrote:

or even 3.15 which also adds the MSVC_RUNTIME_LIBRARY setting

Ah yes, good point. But setting CMAKE_ MSVC_RUNTIME_LIBRARY when it's not supported causes no harm on e.g. CMake 3.5 on Linux.

On 2021-06-03 9:27 p.m., Peter Dimov via Boost wrote:

...

Opinions? So far I have

friendlyanon: 3.14 Glen Fernandes: 3.14 Niall Douglas: 3.8 or 3.9 Alexander Grund: 3.13 or 3.14? Mike: 3.13 or 3.15 Deniz Bahadir: 3.13 Andrey Semashev: 3.7? 3.10?

Have I got everyone's "vote" right?

my opinion (not vote): 3.14 for improved Boost.Python support. FWIW. Thanks for your efforts on this ! Stefan -- ...ich hab' noch einen Koffer in Berlin...

Gavin Lambert wrote:

I have no strong opinion on a specific version, but I do agree that in general Boost shouldn't assume that people will (or can) install a version newer than whatever is already available in their distro.

So pick an expected minimum distro set (likely, what people are most likely to be running a year from now, or other timeframe that seems reasonable) and try to avoid requiring CMake higher than whatever is the minimum common version of that set.

In numeric terms, this translates to 3.10 (bionic), I believe, whose EOL is 2023. I think we can safely discount 2.8 distros and Stretch (EOL, LTS expires in Jan 2022.)

On 6/4/21 5:10 AM, Damian Vicino via Boost wrote:

Is it possible to maybe set a CMakeLists.legacy which is what we distribute right now, and a new CMakeLists.txt requiring 3.10 or something like that. We do not maintain the legacy one and anything new gets to the new one. But we keep it around in case someone wants to still build in an old system. Unless any significant change is done to the source-tree the old one should keep working. Right?

If we don't maintain it then it doesn't work pretty soon. No, I'm opposed to maintaining a *third* build system.

Am 04.06.21 um 03:57 schrieb Glen Fernandes via Boost:

On Thu, Jun 3, 2021 at 9:27 PM Peter Dimov wrote:

...

friendlyanon: 3.14 Glen Fernandes: 3.14 Niall Douglas: 3.8 or 3.9 Alexander Grund: 3.13 or 3.14? Mike: 3.13 or 3.15 Deniz Bahadir: 3.13 Andrey Semashev: 3.7? 3.10?

Have I got everyone's "vote" right? Paul (Bristow) effectively suggested 3.20+.

So would I. The 3.13 is just the bare minimum I warn to never go below. Deniz -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir@benocs.com www.benocs.com Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

Am 05.06.21 um 03:43 schrieb Peter Dimov via Boost:

...

Am 04.06.21 um 03:57 schrieb Glen Fernandes via Boost:

...

On Thu, Jun 3, 2021 at 9:27 PM Peter Dimov wrote:

...

friendlyanon: 3.14 Glen Fernandes: 3.14 Niall Douglas: 3.8 or 3.9 Alexander Grund: 3.13 or 3.14? Mike: 3.13 or 3.15 Deniz Bahadir: 3.13 Andrey Semashev: 3.7? 3.10?

Have I got everyone's "vote" right? Paul (Bristow) effectively suggested 3.20+.

So would I. The 3.13 is just the bare minimum I warn to never go below. Can we think of a specific feature in 3.16 or newer that we'd

Deniz Bahadir wrote: like very much to have? I have good arguments for 3.13, 3.14 and 3.15, but above that, can't think of anything at the moment.

I do not know if you'd like to have the following features "very much", but these stand out to me: * for 3.16:   * `target_precompile_headers()` command was added.   * `BUILD_RPATH` / `INSTALL_RPATH` target properties now support generator expressions.   * `FindPython` and `FindPython3` modules gained options to control which ABIs will be searched.   * CPack now supports multiple configurations. * for 3.17:   * `cmake` gained the "Ninja Multi-Config" generator.     * However, this is nice for the user but irrelevant for determining the minimum CMake version for Boost.   * `target_compile_options()` command now honors the `BEFORE` keyword more consistently.   * The `DEPRECATION` target property was added. * for 3.18:   * `add_library` / `add_executable` commands can now create `ALIAS` targets referencing non-`GLOBAL` `IMPORTED` targets.   * Creation of an `ALIAS` target overwriting an existing target now raises an error.   * `get_property()` / `set_property()` with `SOURCE` gained the `DIRECTORY` and `TARGET_DIRECTORY` options to get/set property from the provided directory scope.   * The same for `get_source_file_property()` / `set_source_file_properties()`.   * The `FetchContent` module `FetchContent_Declare()` command now supports a `SOURCE_SUBDIR` option. * for 3.19:   * The `add_test` command now supports whitespace and other special characters in the name for tests it creates.   * The `find_package()` command can now handle a version range.   * The `file()` command was extended with a lot of functionality.   * `file(GENERATE)` was fixed.   * The `string()` command gained a set of new `JSON` sub command that provide JSON parsing capabilities.   * `FindPython` / `FindPython2` / `FindPython3` gained ability to handle a version range.   * `INTERFACE` libraries may now have source files (*.cpp) added.   * Fixes error of `install(EXPORT)` in certain situations.   * Fix handling `OBJECT` libraries when using "Ninja Multi-Config" generator. * for 3.20:   * The `GENERATED` source-file property is now visible from any directory scope.   * `add_custom_command()` / `add_custom_target()` now support generator expression in their `OUTPUT` and `BYPRODUCTS` options.   * `add_library()` can now handle `IMPORTED` `OBJECT` libraries with multi-architecture configurations. (Mostly affected: Xcode generator when targeting iOS)   * `target_include_directories()` command gained `AFTER` keyword.   * `target_sources` now works with targets created by `add_custom_target()`.   * Compile feature `cxx_std_23` was introduced.   * CPack `DEB` generator now has advanced support for the `dpkg-shlibdeps` program.   * Source file extensions must now be explicit. (CMP0115) Personally, I value the following features from (CMake 3.18 to 3.20) quite high: * from 3.18:   * `add_library` / `add_executable` commands can now create `ALIAS` targets referencing non-`GLOBAL` `IMPORTED` targets.   * Creation of an `ALIAS` target overwriting an existing target now raises an error. * from 3.19:   * Fix handling `OBJECT` libraries when using "Ninja Multi-Config" generator.   * The `add_test` command now supports whitespace and other special characters in the name for tests it creates.   * `file(GENERATE)` was fixed.   * Fixes error of `install(EXPORT)` in certain situations. * from 3.20:   * The `GENERATED` source-file property is now visible from any directory scope.   * `add_library()` can now handle `IMPORTED` `OBJECT` libraries with multi-architecture configurations. (Mostly affected: Xcode generator when targeting iOS) * `target_sources` now works with targets created by `add_custom_target()`.   * CPack `DEB` generator now has advanced support for the `dpkg-shlibdeps` program.

There are undocumented things fixed here and there, such as list(REMOVE_DUPLICATES failing on empty lists with a fatal error, but I don't remember which version fixed that.

Sorry, neither do I. Deniz -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir@benocs.com www.benocs.com Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378