[Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
thiago.macieira at intel.com
Tue Jan 12 17:38:45 CET 2021
On Tuesday, 12 January 2021 02:46:23 PST Giuseppe D'Angelo via Development
> So why do we even ship 3rd parties with Qt in the current form if we
> can't be bother to update them promptly (for bug fixes, security fixes,
> and the like)? Wouldn't it be better to just provide a script (cmake's
> external project, recipe, conan build file, vcpkg, choco, WHATEVER) so
> that the user can download the latest version of 3rd parties
> automatically? Or just NOT provide them and push the problem onto the user?
Convenience and history.
There are two levels of convenience too: building from source and binary
distribution. The former is a historical artefact that we should eventually
get rid of (see Kai's reply). When we had a poor configure script, it was too
difficult to find third-party dependencies, so we ended up adding everything
to Qt itself. That made it easier to build out of the box. To be frank, it
still does when I need to build 32-bit, since my distro of choice for
development (Clear Linux) has no useful 32-bit support and I don't care to
install all the baggage for something I do once every 2 years (last two times
I built 32-bit: 2018-07-12, 2020-12-11).
The binary distribution issue is to reduce the number of DLLs one must
distribute. That can be solved for most of the libraries by just building the
dependencies as static, then compiling them into the Qt DLLs, but that doesn't
remove the problem of forcing users to know they are there and then rebuild
from source on need. I think we should to revisit this and ship all
dependencies as shared libraries / DLLs, but I don't care enough about binary
distribution to join the discussion. And besides, since it's not anonymously
downloadable any more, I care even less.
After all of this, there will be a handful of third-parties that are
integrated very deeply into Qt, like the cryptographic hashes, the FreeBSD
strto(u)ll implementations and TinyCBOR, just to name QtCore dependencies.
Because those are not "unbundleable", we have to apply security fixes
ourselves. Fortunately, there haven't been any in any of them in years.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
More information about the Development