Re: CMake minimum version to support

From: Deniz Bahadir (deniz.bahadir_at_[hidden])
Date: 2021-06-03 14:06:22

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

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_at_[hidden]
www.benocs.com
Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378