[Development] Qt6 repo

[Volker Hilsheimer]

> On 13 Jan 2021, at 22:58, André Pönitz <apoenitz at t-online.de> wrote:
> 
> On Wed, Jan 13, 2021 at 12:48:45PM -0800, Thiago Macieira wrote:
>> On Wednesday, 13 January 2021 10:17:02 PST André Pönitz wrote:
>>> I have a product that depends on qtbase, qtdeclarative and qttool, and
>>> qtdeclarative and qttools refer to different and incompatible versions
>>> of qtbase in their respective dependency.yaml files.
>>> 
>>> How do I build Qt?
>> 
>> There's no such thing.
> 
> You are telling me my day job doesn't exist?
> 
>> Any *product* is built with released versions of Qt, which means you
>> must have exactly the same releases of each module. No other
>> combination is supported.
> 
> 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).

Of course, as we develop on Qt we frequently have local worktrees that point to arbitrary revisions of each submodules, which then also might mean that you have dependency.yaml files pointing to “whatever”. That’s a choice. You can have the same thing with git submodules (checkout random sha in any submodule).


>> 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.

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).


> I am not a big fan of git submodules, nor does the effort spent on failed
> integration attempts look appealing. But effectively the central
> integration is the work that otherwise all users who need to keep up with
> the bleeding edge had to do by themselves.


Our CI system automatically updates the dependencies.yaml file gradually. If a change to qtbase merges, then soon after we will test qtdeclarative against that latest qtbase, and if things pass, the dependencies.yaml file in qtdeclarative will be changed to point to the new qtbase. This then triggers an update of the dependencies.yaml file in other modules.

If you base your checkout on a module at the very end of the dependency chain (qtdoc, I suppose), then you will get a stable, consistent set of all modules identical to what .gitmodules has.


>> For example, I always use the latest of the branch in question for
>> every module, regardless of what's stored in the super module.
> 
> How much do you depend on modules outside qtbase? With qtbase only you
> practically live in a world of a monolithic repo. Working HEAD is
> expected there.
> 
> 
> 
> In any case, the point was that "building according to dependency.yaml"
> doesn't give a "build". Different leave modules will have different
> dependencies on qtbase, which cannot be used at the same time.

See above, I hope this clarifies.

FWIW, try the following in your qt5.git clone repository

$ git submodule foreach 'git checkout origin/dev || true’ # go to the bleeding edge, no matter what .gitmodules says
$ cmake -DSYNC_TO_MODULE="qtdoc" -DSYNC_TO_BRANCH="6.0.0" -P cmake/QtSynchronizeRepo.cmake 

This will result in a local checkout of all submodules that qtdoc depends on, as per the 6.0.0 release:

Checking 'qtdoc' out to revision '6.0.0'
Checking 'qtquickcontrols2' out to revision '9a19ec26f45e7382431f52136f03887cfaa04b66'
Checking 'qttools' out to revision '3fd594493c3ba31639a7515b901554456a90b4c7'
Checking 'qtbase' out to revision 'fc9cda5f08ac848e88f63dd4a07c08b2fbc6bf17'
Checking 'qtdeclarative' out to revision 'fa87052d56526e1529e694fb1c69c69eec38f2fd'
Checking 'qtsvg' out to revision '608054063bf58c555a1871e0a4df9c329c3b6885'

(checking where you are in each submodule will show you that you are at the 6.0.0 tag).


That cmake script just walks the dependencies.yaml file and checks things out accordingly. It would also clone things if needed.

Volker