Re: CMake minimum version to support

From: Mike (mike.dev_at_[hidden])
Date: 2021-06-03 11:55:58

> Gesendet: Mittwoch, 02. Juni 2021 um 18:32 Uhr
> Von: "Peter Dimov via Boost" <boost_at_[hidden]>
>
> 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