> -----Original Message-----
> From: Development <development-boun...@qt-project.org> On Behalf Of
> Volker Hilsheimer

> > I am not asking for *support*. I am asking how to find a recent
> > working combination of Qt modules that I need for porting some code
> > base to Qt 6. Don't tell me to use 6.0 nor to wait for some 6.x.
> 
> Our CI system should prevent that a change to a dependency.yaml file merges
> that results in multiple dependencies to several conflicting versions of any
> upstream library.
> 
> If a change to qttools/dependencies.yaml file adds a dependency to
> qtdeclarative:A and qtbase:B, but qtdeclarative:A depends on qtbase:A, then
> your change won’t merge (Coin will fail during provisioning).

This is a very simplistic way and I can understand why you might think it works 
for you. However, the further you get in the dependency chain the more complex 
your chain is. You gave a nice linear dependency in your example. Imagine you 
have a diamond dependency (e.g. when you checkout webengine):

qtmodulefoo -> qtdeclarative -> qtbase
                        -> qtmodulebar -> qtbase

You approach does not work here. If you make a commit to foo, bar and 
declarative have a different dependency to qtbase you will find two chains 
which might be incompatible. The CI will detect it but the effort to keep every 
module you depend on in sync is huge the further you are away from qtbase. 


 > >> For people developing Qt, once you've checked the Git repositories
> >> out, it doesn't matter whether there's a .gitmodules or not to build.
> >
> > Lacking a monolothic repo the superrepo is currently pretty much the
> > only safe way to find a working combination of reasonably recent
> > states of Qt modules. Sure, one can try HEAD of each module first, and
> > it works sometimes. In a few more cases commenting out a few unneeded
> > bits helps to make it work, but after the third attempt one wants a safe 
> > fall
> back.
> > So far the superrepo delivers that.
> 
> 
> So does the chain of dependencies.yaml files. If the above Coin process 
> works, it
> results in a consistent set of dependencies. The closer you are to qtbase, the
> closer to HEAD your qtbase will probably be. If you want to work on a module
> far down the dependency tree, your qtbase might be older because not all
> dependencies have been updated.

Sadly the set is not consistent. To get a build for foo I might first have to 
push either declarative or bar ahead first. Since the dependency of foo and 
declarative is set independently from each other, chances are they will always 
be out of sync. Especially the less active bar repo will always lack behind. As 
a matter of fact, even if the qtbase SHA's for foo and declarative are 
compatible, the scripts simple SHA checking won't detect it. 

This means a release team will face challenges finding a releasable set of 
SHA's across the modules. To make a decent release you have to face 
synchronizing SHAs in 20 git modules while a common supermodule will do this in 
one set. The trouble of making everything work like a qt5.git update won't 
disappear but is much harder because you have to deal with 20 commits across 
the git module. 

 
> git submodules only updates if everything works. That’s not useful if you
> primarily work on qtdeclarative, so only depend on qtbase (and yes, we want
> people working on qtdeclarative to test their changes against e.g.
> qtquickcontrols2 as well; but I hope you get my point).

*If* you work on declarative you suggestion is fine. qt5.git is not for this 
usecase anyway. It is for a common release. Qt5.git is not for that but for a 
release team or first time user who looks at a complete releasable/usable set 
of SHA's at a given time. One qt5.git update will do that. Your approach 
requires multiple checkouts across several modules behind some magic script. 

--
Alex
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to