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@qt-project.org > https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
