[Development] Proposal: move Qt provisioning scripts and 3rd party components into a dedicated repo

Thiago Macieira thiago.macieira at intel.com
Thu Jul 14 17:32:40 CEST 2022


On Thursday, 14 July 2022 04:51:22 PDT Edward Welbourne wrote:
> Aside from the case of duplicated 3rdparty components, I don't really
> see how this would make it easier.

It's not for us. This does indeed add some work to us, but it's meant to make 
it easier for everyone downstream of the sources. That's everyone building 
from source and everyone using any binary build.

> Indeed, even for a third-party component that's presently used by two Qt
> git modules, if one of those is actively maintained and the other is in
> maintenance mode (particularly if its maintainer has quietly slipped out
> of touch), an update to the third-party component driven by the former
> may break the latter (if we switch to making them use the same
> version). You'd either have to kick the latter out of Qt (in order to be
> able to take in the update) or do the needed maintenance on it, and we
> might not have anyone sufficiently familiar with it to do that robustly.

That's true, but that's not a reason to keep things as-is. That third-party 
content may need updates for one reason or another, so we had better know of 
any issues as soon as possible.

Hopefully before the feature in Qt is productised in the first place. So we can 
kick it out as "depends on third party component that is too fragile, so we 
can't provide long-term support on."

> > Our provisioning process in the CI system could then use the
> > respective “native" build systems of each 3rd party component in that
> > repo to install them as system libraries.
> 
> That's great as long as your builds are always in virtual machines, but
> very very unwelcome for local native builds, unless I'm misunderstanding
> what you mean by "as system libraries".

The use of "system" here is Qt's meaning of it: it's not the bundled copy.

They should be installed to a regular prefix of your choice, which could be 
/usr/local. Installing them to where your Qt build will be installed helps 
simplify CMake runs, but shouldn't be required.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering





More information about the Development mailing list