> On 19. Nov 2024, at 16:58, Thiago Macieira <thiago.macie...@intel.com> wrote:
> 
> On Tuesday 19 November 2024 02:38:36 Pacific Standard Time Alexandru Croitor 
> via Development wrote:
>> I expect its usage will help in certain scenarios which allow using a newer
>> CMake feature during the qt build, but still making the resulting Qt
>> packages compatible with an older CMake version.
> 
> Downgrading CMake should not be allowed, the same way that downgrading GCC or 
> glibc isn't. The CMake that is found in the build environment is as old as is 
> allowed for anything built against the Qt that this CMake built.

While that would be nice for maintenance, it's not the current state of things, 
and it's also taking away something from users which they had so far.

Enforcing that would be a new policy, and has various consequences.

1) Like the fact that CI would need to stop building with latest CMake 3.30.x, 
and instead use the min version for all platforms.

2) Except the current min version (3.16) and the newly pessimistic proposal 
(3.22) isn't enough for certain platforms. 3.16 is not enough for windows and 
possibly android and all static builds, 3.22 is not enough for mac arm, etc.

3) We might  prevent projects from using newer CMake features in our public 
api, because the prebuilt Qt was using an old one. This might be worked around, 
but it's again extra maintenance.

So in summary, I would not take the 'downgrading cmake' argument into account 
for the bumping min cmake discussion, because of the status quo and the extra 
hurdles needed to change that.

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to