[Development] Proposal to raise the minimum CMake version needed to build and use Qt 6.9

[Alexandru Croitor]

Hi again,

It's taking a while to get internal input on what cmake requirements TQtC has for yocto and any other configurations.

Due to platform and module freeze already being in place, and 6.9 branching happening next week, 

I took the conservative approach and bumped the minimum version to 3.22 for 6.9 in https://codereview.qt-project.org/c/qt/qtbase/+/605144

Yocto 4.0 has it, debian 11 and 12 have it, ubuntu 22 and 24 have it, RHEL 8 and 9 have it, so I don't think this should be too controversial.

A qt5.git provisioning change for testing with 3.22 will happen some time after 6.9 is branched.

We can revisit bumping the cmake minimum to a newer version in future Qt releases, depending on how the various dirstos catch up.

Regards,
Alexandru.


> On 21. Nov 2024, at 00:27, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Wednesday 20 November 2024 11:50:47 Pacific Standard Time Manuel Bergler 
> wrote:
>>> That also means this problem will solve itself in about 6 months, when
>>> Debian testing becomes the new stable. So if Alexandru can hold off for
>>> just a while longer.
>> 
>> Which assumes every IT department will immediately update to the new stable
>> Debian, which I highly doubt. And if we don't assume that, then how long
>> should one wait? Until current Debian stable it is EOL?
> 
> No, they won't. but that removes one argument in favour of supporting because 
> "now that it's oldstable, we don't need to support it for the next release".
> 
>> That is debatable. I fixed problems either in the build system itself or the
>> generated CMake config files (or sometimes the absense of them) I
>> encountered
>> as a user of at least a dozen projects using features requiring CMake 3.24
>> or
>> later. But I never upstreamed those because these projects are supporting
>> CMake as old as version  3.5 or sometimes even 2.8.11. And I definitely
>> won't
>> spend the time to figure out how to solve the same issues in these ancient
>> CMake versions just so I can upstream them when a simple solution is
>> available in a more recent version of CMake. So essentially the old CMake
>> verison is a barrier of entry, too.
> 
> I agree and I made that case for C++20 too. This is a balancing act and a 
> subjective call.
> 
> I'm just saying that CMake 3.26 has just too many negatives in its camp. So if 
> Alexandru can hold off for one more release, those negatives go away.
> 
> On the other hand, if he says "Sune is the only developer who would be affected 
> and only for 6 months, isn't contributing anyway, and this change makes me far 
> more productive", I will support him.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Principal Engineer - Intel DCAI Platform & System Engineering
> -- 
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development