> On 13 Jan 2021, at 15:22, Edward Welbourne <edward.welbou...@qt.io> wrote: > > Volker Hilsheimer (13 January 2021 14:37) wrote: >> 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. > > Little detail: init-repository relies on the .gitmodules file and uses > git submodule. So eliminating git submodule in favour of a script that > depends on it isn't an option.
The point I’m apparently failing to make is: we already have a script today that helps people check things out. So, we could just as well have a script that uses the information in dependencies.yaml instead. > In particular, qt5/.gitmodules contains information about module status, > whether each is essential, deprecated, in preview, an addon or to be > ignored. My scripts to generate the api change reviews use this > information to identify which modules are candidates for such a review. > So it's not just init-repository (which does also use status info). > > Not that this argues against more flexible tooling that relegates the > super-module-based structure to the background, but we do still need the > information presently contained in .gitmodules, although perhaps it's > time to eliminate its dependency information in favour of the YAML > config files. > > We could, of course, move the information presently in .gitmodules into > some other file within each module (possibly unifying this with what's > presently in sync.profile and dependencies.yaml), if you're OK with > rewriting init-repository (ideally in python3) as part of your plan. Yes, that meta-data can live anywhere, using .gitmodules is of course convenient as long as we use git submodules, and as I said, for release and packaging purposes (which API review falls under in my mind), having a super-repo might make sense. For working on Qt, the only information we need is “which modules need to be cloned so that it’s possible to build module X from source”. That information is available, once we have module X cloned, as we can walk the dependencies.yaml data to find out what else is needed. Configure could in principle do that, it already checks whether dependencies are missing. Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
