> On 14. Jul 2022, at 17:04, Thiago Macieira <[email protected]> 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.
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
