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

[Alexandru Croitor]

> On 14. Jul 2022, at 17:04, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> Thank you for sending this, Volker. As Alexandru reminds us, this is not a new 
> discussion. We had planned on doing this for 6.0, but didn't get it all the 
> way to the end. Does anyone have a conclusion of why we didn't do it for 6.0? 
> Was it only lack of time, or did we try and come to difficult problems? If so, 
> can you summarise what they were?

I don't remember the ultimate reason, but I remember one of them. Convenience, and by extension, maintenance overhead.

If the 3rd party libraries don't come with Qt, you need to get them from somewhere.

That's relatively easy on Linux with distro-provided libraries.

On macOS there is brew, but the libraries there are not suitable for deployment, they set the deployment target to the host os version, which is too new for Qt.

On Windows there is no de-facto 3rd party library manager afaik. Which means Qt would need to recommend some tool. I think this would apply to macOS too.

Regardless of the recommended tool (conan, vcpkg, whatever), this would be an extra tool that Qt users / customers would need to install, learn, use. The barrier for building Qt gets higher on Windows / macOS.

I don't think not recommending anything, and saying "it's your problem to find and build the libraries" is an option.

And by extension comes the Qt developer maintenance overhead of using such a tool.

Whichever tool we recommend, we'll likely need to fork the recipe repository and possibly mirror the sources. For multiple reasons: patching (where needed, e.g. support an unsupported platform), availability (not depend on other's infrastructure), stability (updates don't fail Qt builds).
Plus trying to catch up with security updates.

Even if we do all that, and Qt developers accept the cost, that's still one more tool users need to use. First use this tool to install dependencies (vcpkg install / conan install / foo install), then use a different process to build qt (configure, ninja install).

An extra maintenance hurdle will be ensuring these tools work fine for non-desktop, non-yocto platforms. I'm not sure if QNX / integrity have some de-facto accepted way of getting 3rd party libraries, maybe they are always used in a yocto context, so the tool would not be needed in that case.

Also, if we're talking about binary releases, then there's the breaking deployment scripts argument that Kai mentioned, now that extra .dll / .so files need will have to be distributed.