[compatibility] define min. cmake version for supported distributions

[Nightwalker-87]

Along with defining new minimum system requirements for libusb (#897), it appears useful to take a similar approach for cmake. Again I did some small research on this topic to find out about the current state of support by various distributions currently maintained.

Here is the result from https://pkgs.org/search/?q=cmake (as of Mar 2020):

3.17.0

• Alpine Edge
• ALT Linux Sisyphus
• Arch Linux
• Fedora Rawhide
• KaOS
• Mageia Cauldron
• OpenMandriva Cooker
• PCLinuxOS
• Slackware Current

3.16.x

• Debian Sid - 3.16.3
• NetBSD 9.0 - 3.16.1
• NetBSD 8.1 - 3.16.1
• NetBSD 7.2 - 3.16.1
• OpenMandriva Lx 4.1 - 3.16.3
• openSUSE Tumbleweed - 3.16.2
• Solus - 3.16.5
• Ubuntu 20.04 LTS (Focal Fossa) - 3.16.3

3.15.x

• Alpine 3.11 - 3.15.5
• FreeBSD 13 - 3.15.5
• FreeBSD 12 - 3.15.5
• FreeBSD 11 - 3.15.5
• openSUSE Leap 15.2 - 3.15.5

3.14.x

• Alpine 3.10 - 3.14.5
• Fedora 31 - 3.14.5
• Fedora 30 - 3.14.2
• Mageia 7.1 - 3.14.3

3.13.x

• Alpine 3.9 - 3.13.0
• Debian 10 (Buster) - 3.13.4
• Ubuntu 19.10 (Eoan Ermine) - 3.13.4

3.11.x

• CentOS 8 - 3.11.4

3.10.x

• openSUSE Leap 15.1 - 3.10.2
• Ubuntu 18.04 LTS (Bionic Beaver) - 3.10.2

3.0.x < ... < 3.7.2

• Debian 9 (Stretch) - 3.7.2
• Slackware 14.2 - 3.5.2
• Ubuntu 16.04 LTS (Xenial Xerus) - 3.5.1
• OpenMandriva Lx 3.0 - 3.4.2

... older cmake versions --> would no longer be supported

• Debian 8 (Jessie) - 3.0.2
• CentOS 7 - 2.8.12.2
• CentOS 6 - 2.8.12.2
• Slackware 14.1 - 2.8.12
• Ubuntu 14.04 LTS (Trusty Tahr) - 2.8.12.2

Looking at this should go to cmake 3.4.2 as the minimum required version to ensure widespread compatibility together with having the possibility to use the more recent 3.x codebase as well.

[slyshykO]

Looking at this should go to cmake 2.8.12 to ensure widespread compatibility.

No, please, no.

[Nightwalker-87]

I think you misunderstood: Just as with libusb, I am only talking about the minimum supported version (necessary to keep it running on the oldest supported operating systems). This does NOT imply that this version should be used (on all systems), if a newer one is working and/or available. If the latter is the case, the newest possible should be used of course.

BTW: The minimum supported cmake version by the stlink-tools is 2.8.7 currently, as I convinced myself with a recent test on windows...

[slyshykO]

I clearly understand what means minimum supported version.
This is means that we can't use new features that provide in newer ones.

[Nightwalker-87]

I don't bother about the following, as they are ruled out anyway by the libusb requirements we are going to set:

• Slackware 14.1 - 2.8.12
• Ubuntu 14.04 LTS (Trusty Tahr) - 2.8.12.2
• CentOS 6 - 2.8.12.2

but I do for CentOS 7 and 8 as these are used in commercial, scientific and R&D environments, being binary compatible to Red Hat Enterprise Linux (RHEL). So I don't think it is a good idea to drop support here because of cmake. They are both LTS versions. Maybe there are further opinions on this. I feel this is an important decision to make and should therefore be widely discussed.

[slyshykO]

The main option for this is download binary of newer cmake that provided by Kitware form https://cmake.org/download/.

And the main question is are we(this project) have enough contributors that will support such many configurations.
Who will test all of them?

My suggestion is to support the latest Debian/Ubuntu, Win10 as main targets until someone didn't take responsibility for another platform.

[Nightwalker-87]

The main option for this is download binary of newer cmake that provided by Kitware form https://cmake.org/download/.

This may work for Windows and macOS (one could implement that similar to as intended to to so with libusb), but is not that straight forward on systems that are package-based, as manual downloaded packages have to integrate more deeply and flawlessly into the respective system.

And the main question is are we(this project) have enough contributors that will support such many configurations. Who will test all of them?

My suggestion is to support the latest Debian/Ubuntu, Win10 as main targets until someone didn't take responsibility for another platform.

I don't think it necessary to test many of these other distributions, but we should basically ensure that the tools can install and it does not fail due to versioning of needed packages. Otherwise we will limit support compared to the current state without any significant need - what I would not really like to do.

[slyshykO]

take into account that automated builds use cmake 3.12 & 3.15 .

[Nightwalker-87]

Yes, but this is the case right now (with cmake 2.8.7+) as well - without any problems. Should a problem occur related to this in the future, we can then address it and raise the minimum requirement just as necessary can't we?

[Nightwalker-87]

Looking at this again, I find that CentOS 7 really is the only system that would hold us on cmake 2.8.12.2, otherwise we would be able to go straight up to 3.4.2 making use of the newer code base. Also I found from research that CentOS is used in scientific and commercial environments, yes, but mainly in the role as a server or workstation for a specific task. It appears related to enterprise environments than to faster paced R&D. Thus the field of µC does not quite seem to address this use case. So we may not loose as much here as I thought we possibly would before.

[Nightwalker-87]

So we'll likely go to the latest available version for the windows compilation from source and consider the proposal above for the package based systems.

[Nightwalker-87]

@slyshykO: Are you fine with this?

[slyshykO]

cmake 3.4 is more better than 2.8

[Nightwalker-87]

Closed with commit 27aa888.