The supported cmake version for buildsystems/cmake/vcpkg.cmake is 3.7.2

[BillyONeal]

I've been doing some testing in order to get ready to ship binary releases of the vcpkg tool for Linux and MacOS, to characterize how we want to make sure everything works, etc. I started with the .NET Core support matrix, and evaluated what was necessary to get vcpkg working with all that. The table is as follows:

I don't think supporting CMake 2.x is practical for the project at this time, and the oldest cmake bundled with a distro that we may care about seems to be CMake 3.5.1 on Ubuntu 16.04 LTS.

Thoughts?

[autoantwort]

If you don't know it: https://gitlab.kitware.com/cmake/community/-/wikis/CMake-Versions-on-Linux-Distros

On mac is it always the newest version through brew

[BillyONeal]

It's true that that's available through brew, but it would be nice to get to a place that we don't need to be bootstrapped through brew.

[dg0yt]

For CMake, see https://repology.org/project/cmake/versions. And there is a badge:

[Neumann-A]

Even if vcpkg says it supports 3.5.1 this isn't really true due to changes to Find<PackageNames>.cmake which might break wrappers.

Considering that CMake is available via snap, pip and apt if configured (https://apt.kitware.com/), I don't see why vcpkg should support such old CMake versions. (Especially since the entry with 3.5.1 seems not to even work today and needs apt reconfiguration any way.....)

Having said that everything > ~2 years seems dropable as such Ubuntu 18.04 is for me the baseline which would be cmake 3.10.2 (but for me the real baseline would be more around 3.15-3.17, because ports like qt6 have cmake_minimum_required(VERSION 3.14...3.19) in the installed -Config.cmake)

[dg0yt]

If you add a thing that wants a recent cmake to your manifest, you need to be using a recent enough cmake. If you don't add such a thing, you don't need such a recent cmake.

The problem is not adding ports, but ports being updated, including dependencies being added.
(What if the proposed zlib wrapper would need CMake 3.21?)

When vcpkg is running, in general, we don't know how the results will be used.

This is okay. But as a user, I want to understand the impact of relying on ports from the vcpkg registry. Even if I can help with contributions, I do need to rely on some firm grounds.

It should also be noted that the qt6 build they did is not entirely a waste because rerunning their configure after downloading a current cmake should be able to reuse the bits :)

The concern is not the time to rebuild Qt. The concern is that I tested successfully with my version of CMake today, and the tiniest wrapper my project loads today will suddenly require a new version of CMake.

[dg0yt]

To draw the picture differently:
Ports are built in a "latest CMake" world.
The toolchain is used by users in a "legacy CMake" world.
Wrappers are published from the "latest CMake" world for use in the "legacy CMake" world.
I'm concerned about control of new CMake requirements slipping into the "legacy CMake" world via the wrappers.

[Neumann-A]

To add to this:
It is especially problematic if "latest CMake" returns something different via find_library|find_package then "legacy CMake" world. As such vcpkg should always recommend the CMake version used within vcpkg.

[BillyONeal]

The problem is not adding ports, but ports being updated, including dependencies being added.
(What if the proposed zlib wrapper would need CMake 3.21?)
[...]
The concern is not the time to rebuild Qt. The concern is that I tested successfully with my version of CMake today, and the tiniest wrapper my project loads today will suddenly require a new version of CMake.

You would have to change the version of zlib or qt you're referencing (or the baseline SHA) for that to happen.

This is okay. But as a user, I want to understand the impact of relying on ports from the vcpkg registry. Even if I can help with contributions, I do need to rely on some firm grounds.

I don't think this is really relevant to the cmake version supported discussion. Again, this is no different vs. today with CUDA or other ports that require system bits to be present.

To draw the picture differently:
Ports are built in a "latest CMake" world.
The toolchain is used by users in a "legacy CMake" world.
Wrappers are published from the "latest CMake" world for use in the "legacy CMake" world.
I'm concerned about control of new CMake requirements slipping into the "legacy CMake" world via the wrappers.

There is nothing vcpkg can do about this. We don't own the caller of buildsystems\cmake\vcpkg.cmake's cmake copy. We could intentionally fail older copies, but that doesn't seem to be helpful to anyone.

It is especially problematic if "latest CMake" returns something different via find_library|find_package then "legacy CMake" world. As such vcpkg should always recommend the CMake version used within vcpkg.

That is our recommendation, but we support things outside of our recommendation. We don't recommend x64-windows-static-md either but lots of people are using it :)

[dg0yt]

@BillyONeal wrote:

... that we need tests for our documented minimum requirements, prompting a reevaluation of what those minimum requirements should be. Clearly, the previous 3.1 policy was not substantiated by actual customer needs. (And was not tested)

#19034 is such a test. It is an elaborated variant of what lead to #18898.

[dg0yt]

@BillyONeal Did you come to any decision? I would update #19034 when 3.5.1 becomes the new standard.

[BillyONeal]

Changed title to 3.7.2 because I don't think we should care about Ubuntu 16.04 any longer.

[dg0yt]

Now we only need a validation facility.