Hi,
Our 3rd party dependencies currently live in the submodules where they are used. For some 3rd party components, that means we have two, sometimes different copies (e.g. assimp in both Qt Quick 3D and Qt 3D, only one of them patched). And it makes it in general messy to maintain an overview of those 3rd party components. We have a responsibility to keep track of those, and to keep things up-to-date. I think that would be easier if we move them into a single repo with all 3rd party libraries. 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. This will speed up the build of Qt (and removes noise from those libraries, some of which are not exactly free of warnings), and it allows us to gradually stop shipping Qt binaries that use the bundled 3rd party stuff. That will be a big step towards reducing our security relevant body of code. It won’t be possible for all 3rd party components and on all platforms, but at least it allows us to move into that direction. For us as Qt developers it might mean that we either have to build that 3rd party repository ourselves (which could still be done as part of the toplevel build process), or install the SDKs from package managers etc. This is nothing new, we do that today already for many dependencies. At the same time, and because it’s quite related, I’d also like to see if we can move all the coin provisioning scripts out of qt5.git and into that same repository. That qt5.git is not just an empty meta-repository that keeps track of the consistent set of submodules, but also has code that might need to be changed in order for submodule updates to succeed, has more than once caused problems. Moving the provisioning code and coin rules into a submodule untangles that. We’d use the dependency mechanism that we have, ie. qtbase would declare a dependency to that new repository, and the submodule update process keeps qtbase’s dependencies.yaml updated. Building qtbase on its own would still work as long as the necessary dependencies are provisioned; if they are not, building them from the new repo is one option, using the native system libraries is another. As mentioned, this would be a gradual process, one 3rd party dependency at a time and figuring out what it takes to make this work on all platforms. Some 3rd party code might have to stay where it is today. What do you think? Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
