On 23 Aug 2023, at 08:35, Haowei Hsu <hwhsu1...@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

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

Reply via email to