> -----Original Message----- > From: Development <development-boun...@qt-project.org> On Behalf Of > Volker Hilsheimer > [...] > I think that’s by far the exception though. Most 3rd party components we > use have well defined, stable APIs.
I think it's the other way round, at least if you go by the number of qt_attribution.json entries 😊 Checking only Qt Core, we list about 18 third-party code attributions. Only 3 of them can be configured to use a system library instead. Anyhow, the examples with proper upstream project + a build system are arguably the bigger ones, and the ones that are interesting from the security perspective (ZLIB, PCRE2). But don't expect that we get rid of even the majority of third-party attributions by saying 'we use system libs'. Also, let's not forget the elephant in the room: Chromium, and the myriad of further dependencies it ships itself. I wouldn't hold my breath for them to provide a stable API :/ > We can expect that a system that runs Qt has a system libpng.so. We don’t > need to build libpng sources into Qt just because our build environment > doesn’t have libpng-dev provisioned. Though luck on Windows 😊 We need to find a solution there. This might be Conan, vcpkg, or our own build system. But we really shouldn't make the steps to get a working copy of Qt on Windows even more elaborate than it is right now. > Yop. Nothing is going to happen immediately. If we can agree that the goal is > worthy the effort it will take, then setting up a new submodule where we > can experiment with some of the obvious candidates (zlib, libpng, freetype) > will probably find the new tangles :) I'm all for experimenting with these. Let's set up some requirements though: - We need a setup on Windows that is practical - We need a solution for _all_ supported platforms + compilers, including cross-compilation - static builds still need to be supported (so that the third-party lib is statically linked into a static Qt) My expectation is that we must still maintain our own forks for almost all 3rd-party libs, if only for supporting exotic platforms + build system issues. But I'd be happy to be shown otherwise. For Windows specifically: My understanding is that we want to use separate third-party .dll's wherever possible, also for the official binaries that we provide. Mind you that this will break a lot of customer deployment scripts, and potentially can cause some dll hell. It also doesn't make Qt appear lightweight when you must deploy 10+ dll's for a "hello world" :/ Regards Kai _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
