> On 13 Jan 2021, at 14:17, Dominik Holland <dominik.holl...@qt.io> wrote: > > Am 1/13/21 um 1:19 PM schrieb Allan Sandfeld Jensen: > >> On Mittwoch, 13. Januar 2021 13:07:00 CET NIkolai Marchenko wrote: >>> that's ... kinda what you're supposed to avoid... at least as far as I >>> understand the convo earlier. so that two major versions aren't pushed to >>> the same repo confusing people. >>> >> I don't see any problems with that. It is how all the other modules are used. >> >> 'Allan >> > Why not create a qt6 super repo, which host qt6 for now and just create > a alias qt.git which always points to the latest qt release. > > Later this could point to a qt7 release. I guess we don't want to go > back to a monorepo, but we never know, so this would atleast help to not > block this road... > > Dominik
Let me make a more radical proposal: The information about which modules depend on which others modules lives in each module’s dependency.yaml file. This information includes the sha1 of the modules it has last been successfully tested against. This information is (inconsistently) duplicated in .gitmodules. So proposal: * 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. Note that the cmake top level build system is already operating on the data in dependency.yaml to figure out the order in which things need to get configured. It doesn’t care about .gitmodules. That cmake tooling also knows how to fetch the dependencies needed (see https://code.qt.io/cgit/qt/qt5.git/tree/cmake/QtTopLevelHelpers.cmake#n155). This can in theory (and in practice; that’s what I’m using) replace the init-repository script to some degree (commit hooks and other gerrit shenanigans require some extra love, I suppose). <tangent> The main problem I see with us using git submodules is that it makes it a royal mess to work with git worktrees. I have separate worktrees for all modules (ie $ git worktree add ~/qt/dev/qtbase dev $ git worktree add ~/qt/6.0/qtbase 6.0 $ git worktree add ~/qt/515/qtbase 5.15 repeat for most other modules), which makes it easy to work on several branches, test changes in several branches, and cherry-pick changes across. I can’t use (or at least there is no point in using) git submodules. </tangent> * move the top level build system files into a dedicated repo That dedicated repo has branches for different Qt versions, nothing special about it. We shall perhaps not call it “Qt Build System” :P 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. The workflow with such a setup would not be fundamentally different from today. You clone one thing (build system repo instead of qt5.git), you run a script and tell the script what you want to work on to get all the things you need. You build Qt more or less as before; the configure script lives in the build system repo rather than in some Qt super module clone. The file system structure will be a bit different. Advantage: * no (inconsistently) duplicate information in .gitmodules vs dependency.yaml files * cloning and building are based on the same information (dependency.yaml files) * easier to work with multiple worktrees * any Qt add-on module (which can live on any repository server) can be treated the exact same way as the default modules. Put a dependency.yaml file into your add-on repo, and you’re done Fringe benefits for git submodule dislikers: * git status from git submodules being changed won’t make things light up in IDEs * no need to deal with git submodules at all Cheers, Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
