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

[Manuel Bergler]

On Wed, Nov 20, 2024 at 10:27:24AM -0800, Thiago Macieira wrote:
> On Wednesday 20 November 2024 01:36:07 Pacific Standard Time Manuel Bergler
> wrote:
> > > We still have the Debian stable problem, though.
> >
> > Doesn't the exact same logic apply here, though? Why upgrade Qt but not
> > CMake? Given that you'll only have to upgrade CMake on the dev machines,
> > whereas a verison of Qt that is newer than what is available by default on
> > your OS will need to also be deployed to all target machines and/or to
> > your users, this doesn't seem to make much sense to me.
>
> Not exactly, because it's a different audience. We're talking about a developer
> trying to develop Qt, not someone trying to deploy an application to a system
> that can't be otherwise updated. Debian is an OS of choice for CIs and
> workstations because of its stability. I can certainly see a situation where
> developers are given access to a beefy server to do their development on,
> because developing on their Windows laptops (often encumbered with IT-required
> virus and IP-protection scanning) is not acceptable, and the IT admins install
> a stable Linux distribution to lower their maintenance costs.

That is precisely the situation I'm in at my workplace. We have IT-managed
development servers that are still on Ubuntu 20.04 LTS. But we also have
a network share all developers have access to that contains more recent
versions of all parts of the toolchain - compilers, third-party libraries, and
of course CMake. Additionally I have another set of tools that I use frequently
installed to my home directory, for example a recent version of heaptrack.
So just because the OS installed by IT doesn't include a particular tool
doesn't prevent you from managing it yourself.

> 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?

>
> > Why should one prioritize folks that want to use the bleeding edge version
> > of a particular third-party library, yet can't be arsed to spend 5
> > minutes to compile a new version of CMake from source. Everyone
> > able to compile Qt from source should have no trouble building CMake
> > themselves either, so I don't get why libraries stay on ancient versions
> > of CMake just because some users might not have a newer version by default.
>
> Barrier of entry.

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.

And if barrier of entry is the only reason not to use a newer version of CMake
there are other ways to solve that issue. Qt could provide dev containers,
or use a package manager to automatically fetch the correct CMake version, or
include the less than 5 lines of bash required to fetch the CMake sources and
build them in the README.



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