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