[boost] CMake minimum version to support

[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?



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Glen Fernandes via Boost]

On Wed, Jun 2, 2021 at 12:32 PM Peter Dimov wrote:
> 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.

Based on your list and the versions of CMake shipping with the latest
distributions from https://pkgs.org/download/cmake I'd vote for at
least 3.14.

[friendlyanon via Boost]

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.

You could argue that hacking around with CMAKE_SIZEOF_VOID_P is common
enough, but I don't think hacks have any business is a freshly set up
project.

For reference:

https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#command:write_basic_package_version_file

[Peter Dimov via Boost]

"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.

[Niall Douglas via Boost]

On 02/06/2021 17:32, Peter Dimov via Boost wrote:
> 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.

Some observations:

- RHEL7 ships with cmake 3.9

- Ubuntu 18.04 LTS ships with cmake 3.10

- Ubuntu 16.04 LTS ships with cmake 3.5.

I can tell you that my users used to complain loudly if cmake 3.5 wasn't
supported, probably because of Ubuntu 16.04 LTS. A while back I bumped
my minimum cmake to 3.8, and users have not complained.

Me personally, I think cmake 3.8 or 3.9 is a good minimum, as it doesn't
needlessly inconvenience RHEL7 users. Speaking from personal experience,
everything added to cmake after 3.8 can be fairly easily worked around
or done without, whereas the lack of enough compile features flags is a
real pain.

Niall

[Peter Dimov via Boost]

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.

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.

[Andrey Semashev via Boost]

On 6/2/21 7:32 PM, Peter Dimov via Boost wrote:
> 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?

For reference, CMake versions available in some common Linux/BSD distros
(stock versions):

Debian Stretch: 3.7.2
Debian Buster: 3.13.4
Ubuntu Bionic: 3.10.2
Ubuntu Focal: 3.16.3
RHEL 7.9: 2.8.12.2
RHEL 8.4: 3.18.2
CentOS 7.8: 2.8.12.2
CentOS 8.2: 3.11.4
Gentoo Stable: 3.18.5
ALT Linux 9.0: 3.13.4
ALT Linux 9.1: 3.16.3

FreeBSD 13.0: 3.19.2
OpenBSD 6.8: 3.17.2
OpenBSD 6.9: 3.19.24

Package versions for Debian and Ubuntu taken from their respective web
sites, the other - from distrowatch:

https://distrowatch.com/dwres.php?resource=package-in-distro&pkg=cmake

I think, it would be preferable if Boost could be built on most
currently maintained distros with stock CMake.

[Julien Blanc via Boost]

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 via Boost]

> - 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.

I use find_dependency there which requires 3.9.

> - 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?

Given that using CMake for Boost is optional itself, I'd go for 3.13 at
least (based on Andreys list of OS cmakes) and would even suggest 3.14.
Having Boost.CMake work well is IMO more important than supporting users
who want to install Boost with CMake and insist on using the OS cmake.

Especially as this is a long-term thing, so distros might already
upgrade in the meantime and that installing cmake is reasonably easy.

[Paul A Bristow via Boost]

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.

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.

[Deniz Bahadir via Boost]

Am 02.06.21 um 18:32 schrieb 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?

I never understood why users were so lazy to get the latest CMake
version and insist on using old, outdated and buggy versions which were
supplied with older Linux distributions.
I always recommend to users to use the latest CMake version. (They are
very good with keeping backwards-compatibility.)
Kitware provides binaries for Windows, Mac and Linux and even has an APT
repository for Debian-based Linux distributions. And even building CMake
oneself is also quite simple.

If Boost is really hesitant to require this of its users I recommend to
collect the features that you need and require at least the latest
version of CMake which brings in these features.

Something I always recommended was to go with at least CMake 3.13.
This one is able to treat OBJECT library targets (almost) identical to
other types of CMake targets and also contains some
simplifications/unifications to the `target_*` commands.

If, however, for example generated files are used and therefore the
`GENERATED` property, I recommend to take at least CMake 3.20, because
that one makes it possible to see that property from any directory.

My 2 ct.
Deniz

PS: A short note/disclaimer: I know about and especially mentioned these
specific features, because I provided them to CMake. (I needed them and
they were missing from CMake.)

--
BENOCS GmbH
Dipl.-Inform. Deniz Bahadir
Reuchlinstr. 10 D
10553 Berlin
Germany
Phone: +49 - 30 / 577 0004-22
Email: deniz....@benocs.com
www.benocs.com

Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378

[Alexander Grund via Boost]

> If Boost is really hesitant to require this of its users I recommend
> to collect the features that you need and require at least the latest
> version of CMake which brings in these features.

^This

While I agree that upgrading CMake is easy, needlessly requiring the
latest version is counterproductive.

I know if one instance at least where I can given an example: For
automated installations on HPC systems "toolchain generations" are
defined. And in each generation only 1 version of each software can
exist. The base is then e.g. GCC 9.3.0 and OpenMPI 4.1.0 and then
software gets successively added as needed.
Hence when CMake X is added and later Boost is released and that is
added but requires CMake Y (with Y > X) it would mean that it cannot be
used in this toolchain generation and people need to wait till the next
update.

So I'd focus on 2 points:
- Use the CMake version that is required for what is used
- Try to avoid CMake versions more recent than, say, 1 year, maybe 2.
This has also the benefit that things may stabilize with patch releases.

And for completeness: CMake does deprecate and eventually remove stuff.
So there are (rare) instances where it is not backwards compatible. And
even though often policies are used for such breaking changes, I'm quite
certain even projects claiming they support CMake X do in fact not. Also
note that requiring a more recent CMake enables all policies introduced
until then, so behavior may change just by upgrading the required cmake
version.

[Andrey Semashev via Boost]

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.

[Niall Douglas via Boost]

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

[Mike via Boost]

> Gesendet: Mittwoch, 02. Juni 2021 um 18:32 Uhr
> Von: "Peter Dimov via Boost" <bo...@lists.boost.org>

>
> 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.
- 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

[Niall Douglas via Boost]

On 03/06/2021 12:55, Mike via Boost wrote:

> 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.

I believe VS2017 ships with cmake 3.12.

Niall

[Deniz Bahadir via Boost]

Am 03.06.21 um 13:55 schrieb Mike via Boost:

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).

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....@benocs.com
www.benocs.com

Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378

[Alexander Grund via Boost]

>>
>> 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.

I would rather not use the latest just because.

Use 3.15 if you want. That seems to be the version that added some stuff
that is useful and used, but I see no need purposely and unnecessarily
introduce limits.

[Peter Dimov via Boost]

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.

[Peter Dimov via Boost]

Paul A Bristow wrote:
> 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.
>
> 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.

Unfortunately, Boost is widely used on unpopular platforms where acquiring
the latest CMake might not be as easy (e.g. non-x86, non-Linux UNIX.)

Although as Alexander pointed out, using CMake is "optional" at this point
because there's always b2, so we might be able to get away with it.

[Andrey Semashev via Boost]

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.

[Alexander Grund via Boost]

> 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.

Hm, I remember there was some issue there but can't remember which one
it was. While it is possible that I removed those additional args
somewhere in the process I'm quite sure there was a real issue. Maybe
the version argument was required In 3.5 or something like that.

However I think 3.9 is a good minimum anyway, as we have 3.20 now it is
also old enough ;)

[Peter Dimov via Boost]

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.

[Peter Dimov via Boost]

Andrey Semashev wrote:
> But I think the real question Peter is asking is what minimum version Boost
> superproject and common CMake scripts should require.

Kind of. The main question I'm asking is when I need to get irritated when
a library does cmake_minimum_required(3.51) and breaks the entire Boost
build as a result.

But a higher minimum version also allows me to skip coding workarounds,
which is good.

The main significance of "Boost minimum version" is that we'll be testing it.
Everyone will of course be free to do whatever in their CMakeLists, as any
enforcement is virtually impossible.

[Mike via Boost]

> Gesendet: Donnerstag, 03. Juni 2021 um 16:06 Uhr
> Von: "Deniz Bahadir via Boost" <bo...@lists.boost.org>

>
>
> 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

[Deniz Bahadir via Boost]

Am 03.06.21 um 17:53 schrieb Mike via Boost:

>> Gesendet: Donnerstag, 03. Juni 2021 um 16:06 Uhr
>> Von: "Deniz Bahadir via Boost" <bo...@lists.boost.org>
>>
>>
>> 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
>

That is true. That is my personal recommendation.
And it is due to the fact that I do not see a good reason for Boost
needing to support old versions for a new and optional feature.

I dot not know exactly, what bugs were fixed and what new features were
introduced in CMake between 3.13 and 3.20.
I know of some, because that were problems for the project I was working
on until I was able to fix these in CMake. So for me personally, CMake
3.20 is a minimum requirement.

Then of course, some of these changes have to do with packaging / CPack
which probably is no big concern for Boost (yet).

Deniz

--
BENOCS GmbH
Dipl.-Inform. Deniz Bahadir
Reuchlinstr. 10 D
10553 Berlin
Germany
Phone: +49 - 30 / 577 0004-22
Email: deniz....@benocs.com
www.benocs.com

Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378

[Rainer Deyke via Boost]

On 03.06.21 10:03, Paul A Bristow via Boost wrote:
> 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.

"What we do for b2" is distribute the source code along with Boost,
along with a shell script that builds and installs b2 in the build
directory, ready to use for building Boost, all without requiring root
access. That's quite a bit more than just pointing the user to a
third-party download that probably wants to install at the system level,
replacing the system-provided CMake.

The difficulty with taking the same approach for CMake is that CMake has
its own set of requirements. b2 can be built in just about computer
that has a shell and a C++ compiler. CMake requires GNU Make plus a
whole bunch of development libraries.


--
Rainer Deyke (rai...@eldwood.com)

[Deniz Bahadir via Boost]

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....@benocs.com
www.benocs.com

Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378

[Peter Dimov via Boost]

> 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?

[Stefan Seefeld via Boost]

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 via Boost]

On 4/06/2021 1:27 pm, Peter Dimov 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?

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.

[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+.

Glen

[Peter Dimov via Boost]

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.)

[Damian Vicino via Boost]

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?

[Peter Dimov via Boost]

> 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.

[Deniz Bahadir 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.

Deniz

--
BENOCS GmbH
Dipl.-Inform. Deniz Bahadir
Reuchlinstr. 10 D
10553 Berlin
Germany
Phone: +49 - 30 / 577 0004-22
Email: deniz....@benocs.com
www.benocs.com

Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378

[Andrey Semashev via Boost]

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.

[Phil Endecott via Boost]

Glen Fernandes wrote:
> 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+.

Of the systems where I build Boost:

Debian Stable has 3.13, but "backports" makes available 3.16.
Homebrew on MacOS has 3.19.



Regards, Phil.

[Peter Dimov via Boost]

Deniz Bahadir wrote:
> 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
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.

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.

[Deniz Bahadir via Boost]

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

> Deniz Bahadir wrote:
>> 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
> 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....@benocs.com
www.benocs.com

Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378

[Peter Dimov via Boost]

FWIW, I found another reason to require at least 3.9:
the capture groups of if(MATCHES) - the variables
CMAKE_MATCH_1, CMAKE_MATCH_2, etc, don't work
on earlier versions.

I didn't even know.