[Development] Qt modules, API changes and Qt 6

Frederik Gladhorn Frederik.Gladhorn at qt.io
Wed Jan 30 10:35:31 CET 2019


On onsdag 30. januar 2019 09:17:11 CET Alex Blasche wrote:
> >From: Development <development-bounces at qt-project.org> on behalf of Jedrzej
> >Nowacki <Jedrzej.Nowacki at qt.io>>
>  >Personally, I also do like the idea of monolithic repo, while keeping
> >
> >modularization on the logical / build level. In our current state I see two
> >major problems:
> >- our build is quite monolithic in practice. For example qtbase always
> >needs to be build. CI currently caches builds on repository level (caches
> >results of make install) with monolithic repository the optimization would
> >need to be reconstructed on the build level. Conceptually it is good, but
> >someone would need to do the work.
> >- as a consequence of a partial build, the repository may be in a broken
> >state, for example not compiling. It can be solved by time based world
> >rebuilding and tagging known good revisions, but some policies would need
> >to be created.
> 
> I am clearly missing something here. Could you please outline why such a
> monolithic repo would be good? As you pointed out yourself, the conceptual
> problem that different libraries won't walk in lockstep remains and
> segmented builds continue to be desired. Sure, repo checkout is easier but
> as long as segmentation exists I fail to see the advantage.

A mono repo is good because it allows changing API across modules in on go.
There are a bunch of things speaking in favor of this, but the practicalities 
are quite hard - how would we do CI for this? How would we merge between the 
mono repo and the existing individual repos?

In the end we discarded the idea as impractical for the time being. It would 
be possible for someone to champion it by showing a lot of git magic and 
coming up with a good testing strategy where things work together nicely, but 
I fear that the complexity is quite high. With unlimited resources we could of 
course test everything in the repo for each change. Other options would be to 
try to figure out which tests are relevant for which change. Doing that cross-
platform in a sensible way seems quite non-trivial as well.

Cheers,
Frederik


> 
> --
> Alex
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development







More information about the Development mailing list