[Development] How to use `init-repository` properly to clean up the working tree after checking out?

[Volker Hilsheimer]

On 23 Aug 2023, at 08:35, Haowei Hsu <hwhsu1231 at gmail.com> wrote:

Hello, Thiago.

No, I mean, why do you want to get Qt 6.2.4 in the first place?

I didn't say that it had to be 6.2.4. In fact, I've also tried to build other Qt6 releases, such as: 6.1, 6.3, 6.5... etc.
However, I found during the process that when I initialize submodules in the dev branch and then checkout to the 6.2.4 branch, the issue arises:

The two redundant submodules, qtlocation and qtspeech, remain,
which causes problems when using configure.bat and building targets.

Therefore, I want to figure out why it happened and how to solve it.

The problem is that Qt Location and Qt Speech were brought back into Qt after 6.2, so if the super-repository is checked out to e.g. the 6.2.4 tag after being checked out to a revision where they did exist (such as dev), then they become inactive in the .gitmodules files (as opposed to be removed entirely, like qtgrpc, which never existed before it was added), but they are still in your worktree.

However, any `git submodule` operations will not touch them. The top level build system however cares about code that’s actually there, not about git. It iterates over each subdirectory with a CMakeLists.txt file and adds that to the build. So it will try to build e.g. qtlocation. And since that remained checked out at a current revision, and depends on a corresponding qtbase version that is no longer checked out, it can’t be built.

You won’t have that kind of problem with projects that don’t use submodules, or where the list of submodules doesn’t change between interesting revisions. I don’t know in which category cmake falls.

I avoid changing my checkout of Qt repositories, and of qt5.git in particular, and instead use worktrees for the branches that I care about. Otherwise I’d have to rebuild the whole world every time I want to move between dev and a stable branch. And I use worktrees because then I can cherry-pick locally between branches.

You can use that as well:

To build a specific Qt version, add a worktree for your qt5.git clone:

```
$ cd ~/qt/qt5 # your clone of qt5.git
$ git worktree add ~/qt/6.2.4 6.2.4
$ cd ~/qt/6.2.4
$ ./init-repository -f
```

If you use `git submodule update —recursive` instead of init-repository, then you will still end up with qtlocation and qtspeech being cloned and checked out to an old, probably pre-port revision. But they won’t have a CMakeLists.txt file as they weren’t ported yet, so configure and the toplevel build system should ignore them.

(Note: this will not create worktrees for the submodules, but instead clone them; my local setup adds a worktree for each submodule explicitly, messing up the corresponding qt5.git status, but I don’t care because all I want from that is the toplevel build system).

Volker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230823/77ce5b2b/attachment-0001.htm>