[Development] Qt6 repo

Volker Hilsheimer volker.hilsheimer at qt.io
Thu Jan 14 10:50:57 CET 2021

> On 13 Jan 2021, at 17:28, Thiago Macieira <thiago.macieira at intel.com> wrote:
> On Wednesday, 13 January 2021 05:37:21 PST Volker Hilsheimer wrote:
>> * stop using git submodules
>> Using them serves no real purposes anymore. We anyway have our own scripting
>> in form of init-repository to avoid that people have to deal with that
>> stuff.
> Please don't. In fact, I recommend the opposite: delete the Perl script and 
> use submodules properly.

The init-repository script does some extra work that is supposed to give people a leg up though, such as setting up commit hooks and remotes in all submodules.

FWIW, I used it once, when I did the first clone, to do exactly that kind of stuff. I never need it afterwards, and I rarely have to deal with git submodules (and I’m not sure if it’s supposed to be used afterwards), since I work in worktrees.

So, I think we can kill both the init-repostory script and .gitmodules as a way to get Qt; but some sort of script that sets other git things up locally might be the price we have to pay by using a repository service that people typically are not familiar with.

> I do use "git pull --recurse-submodules", "git submodule update", "git 
> submodule foreach", etc. often.
>> The super-module, if we want to have it at all, can then be just the single
>> .gitmodules file. It might be relevant for the release team, and for those
>> of us who prefer to work with git submodules for… reasons. Ok, so I’m not a
>> fan of git submodules. Either way, it avoids the mixing “real code” (like
>> build system and coin configs) and submodule updates in the same
>> repository, which has historically caused an unfortunate entanglement of
>> unrelated things.
> That works for me.
> The primary and official way to build Qt is each submodule individually, with 
> "make install" in sequence. The merged content in a single build is secondary 
> and a convenience anyway.
> PS: do uninstalled builds even work with CMake? That was a (mis)feature of 
> tmake and qmake…

Well, IF the canonical way of building Qt is to clone each submodule individually, then anything we provide as convenience to work with toplevel builds is just sugar on top anyway, and as long as it doesn’t get in the way it’s no problem.

But, our wiki [1] documents that building Qt from git involves cloning of qt5.git, running init-repository, and then a top-level build.

[1] https://wiki.qt.io/Building_Qt_5_from_Git

And while I don’t use top-level builds in Qt 5, in Qt 6 with cmake and ninja I find them incredibly convenient. Being able to run

$ ninja tst_class_I_fixed_check

and ninja rebuilding everything that needs to be rebuilt across all modules before running the test is a huge timesaver.


More information about the Development mailing list