[Development] Specifying module dependencies

Simon Hausmann simon.hausmann at theqtcompany.com
Mon Jun 15 08:52:52 CEST 2015


On Friday, June 12, 2015 09:47:44 AM Oswald Buddenhagen wrote:
> On Thu, Jun 11, 2015 at 08:30:37PM +0000, Gladhorn Frederik wrote:
> > On Thursday 11. June 2015 18.47.40 Oswald Buddenhagen wrote:
> > > you won't get rid of the redundant dependency specifications anyway,
> > > because qt.pro (and the sync.profile's) are about repository deps,
> > > while the module's requires() (and whatever other methods they use
> > > to exclude themselves) are about module (and non-qt) deps.
> > > 
> > > about sync.profile and pinning, i think you didn't consider
> > > non-mainline branches in your plan. you need to specify the branches
> > > of the other modules you want to build against *somewhere*. nowadays
> > > that could be actually qt5.git's .gitmodules, as it now contains the
> > > branches. of course, this implies branching qt5.git for every
> > > CI-controlled non-mainline branch. this actually sounds quite
> > > logical. i'm all for removing the inter-repo deps from sync.profile
> > > - it was never meant to contain them in the first place.
> > 
> > I'm concerned about using qt5.git to hold the information of module
> > dependencies since it will never be complete
> 
> this will always be the case at some times as long as the information is
> held redundantly.
> 
> > and the information should imho be with the module, not in some other
> > git repository. From that point of view sync.profile is preferable.
> > 
> > The reason is that it doesn't scale - when a new module is created, it
> > shouldn't have to require registration in qt5.git.  This also applies
> > to modules that are not (yet) part of official releases or that are
> > proprietary for whatever reason. All of these modules don't belong in
> > qt5.git.
> 
> new modules can be registered before they enter mainline - there are
> plenty of precedents for that.
> proprietary modules can be added in a proprietary branch.
> 
> this is really the same discussion as specifying sources belonging to a
> project by wildcard. i'm fairly firmly on the 'nope' side on this one
> (see discussion in https://bugreports.qt.io/browse/QBS-58).
> 
> > Therefore I would propose containing the information of what
> > dependencies a module (on the git repository level) has inside the
> > module itself.
> 
> that must include the branches. these will inevitably be redundant with
> qt5/.gitmodules. and we've recently seen that this redundancy is
> actually causing problems.
> 
> On Fri, Jun 12, 2015 at 09:05:09AM +0200, Joerg Bornemann wrote:
> > But it's easily possible to deduce information about repository
> > dependencies from module dependencies, isn't it?
> 
> to do that, you need
> - a full understanding of the build system. virtually impossible to get
>   with qmake.
> - the repositories themselves, so the build tool can find the modules in
>   them. this does not help when you need to decide which repositories
>   you need to clone in the first place.
> 
> it all boils down to the fact that aggregation must happen top-down.
> we could unify the implementation somewhat by adding more custom fields
> to .gitmodules instead of duplicating some of the information in qt.pro.
> but there is no way around the fundamental requirement. even with qbs.

Perhaps there is a misunderstanding here, so let me confirm also what Joerg 
said: At this point we're interested in discussion repository dependencies. I 
understand that are somewhat parallel to the qt module dependencies and I also 
understand that a full build system "evaluation" is required to entirely 
reduce the duplication. However at this point we're interested in taking one 
step into a more modular direction for the repositories only.

As it stands today, in order for a repository to be built by the current CI 
system, it has to be included in qt5.git. This is an unfortunate artifact of 
the way the system builds but I'm not convinced that it is a restriction we 
want to impose on contributed repositories. Therefore the new CI system does 
not require this.

In order for a module to be part of the official Qt release, it also has to be 
part of qt5.git. I think that part is a reasonable requirement, for the 
convenience of the users of Qt who would like to build the product in one go.
I for one have no intention of trying to change this part.

We also do have at this point a duplication of repository dependencies in 
qt.pro as well as in the repository sync.profile. I do believe that we can 
eliminate this dependency without any downside, based on your idea of placing 
a .pri file into the top-level directory of each repository. That can replace 
sync.profile and qt.pro as well as the CI system can use that file instead of 
the CI system using sync.profile and the build system using qt.pro.

I think such a step would be an improvement that we should pursue. As 
consequence  we could lift the requirement that in order for a module to be 
built by the CI system it has to be part of qt5.git. I do recognize that it is 
not the perfect solution - it isn't fully flexible in terms of building the 
code in one repository against a flexible set of modules coming from 
repositories in different branches.

I think it would boil down to:

1) If you want your Qt module(s) to be part of a Qt release, then your 
repository needs to be registered in qt5.git and it will following the Qt 
product branching. So your 5.6 branch has to build and work against the 5.6 
branch of all the modules coming from depending repositories.

2) If you are not part of a Qt release yet but you would still like to use the 
continuous integration system, then your code has to build and work against 
the dev branch of the modules coming from depending repositories.

Not perfect, no :). But an improvement IMHO. I think we want modules to become 
part of the Qt release and product, and we also want to allowing for automated 
testing as soon as possible.

Simon



More information about the Development mailing list