[Kde-scm-interest] Package splitting

[Marcus D. Hanwell]

On Wednesday 27 January 2010 18:58:59 Oswald Buddenhagen wrote:
> On Wed, Jan 27, 2010 at 10:46:52PM +0100, Thiago Macieira wrote:
> > [...] The build rules are: [...]
> 
> why not (mostly) keep our current layout in form of a meta structure (be
> it git submodules or not)? build order would be determined by cmakelists
> which declare subdirectories (and *nothing* else) as ever. breaking out
> of that layout would happen at own peril, but any breakage will be
> quickly detected anyway (as the projects' cmakelists must be
> self-contained and dependency-complete).

Sorry about being so late to the party, catching up on emails... At Kitware we 
are also working on a migration from CVS (never made it to SVN) to Git. We 
currently use funky filesystem magic to have a VTK subdirectory in ParaView3 
be the real VTK CVS directory, and similar magics... So we have been thinking 
a lot about some similar issues.

I have also worked on Kalzium off an on, and Avogadro (which migrated to Git 
more than a year ago). Personally I have always hoped to see the KDE modules 
split up a little more, and the Git migration seems like the perfect time. I 
am working on the rules for the kde edu moduel too.

We are working through similar workflow possibilities. I have been 
experimenting with what we can get out of submodules, and we have also been 
looking at possible changes to Git in the future, to facilitate a smoother 
workflow and recover some atomicity in supermodules.

For most of my work on ParaView and VTK I would rather see the two decouple. 
With Kalzium it was always decoupled between Kalzium and libavogadro, but may 
be I never found the ideal workflow there. Lots of work to do there now that 
trunk is open again. 
> 
> On Wed, Jan 27, 2010 at 10:56:21PM +0100, Thiago Macieira wrote:
> > And here's a suggestion to address those points, so a modification to the
> > rules in the earlier email.
> > 
> > Instead of having 4 stages per category, we actually have:
> > 	libs
> > 	libs2
> > 	libs3
> > 	...
> 
> you know, sysvinit is now moving away from fixed priorities to a
> dependency-based system ... ;)
> anyway, my private build script does effectively the same, so it isn't
> that bad as such. :D

I got the initial checkouts down to, 'git clone git.url', and 'git submodules 
update --init'. You can have the submodules checkout master by changing the 
.gitmodules file to use 'update = merge' in the submodule section. As a 
Kalzium developer when I first started out I never liked that I was supposed 
to checkout the entire module just to work on Kalzium, and always wanted an 
easy solution to just build that one app. See the example I pushed here,

http://gitorious.org/kitware/babytitan/blobs/master/.gitmodules

We are working on a shorter timeframe (hopefully migrating within the next few 
months). I am still working on issues with workflows, and moving over to Git 
from CVS. Splitting would also change the work I need to do with CDash/CTest, 
either way we have a solution but I prefer splitting.

I didn't spot a good solution to moving apps into modules and preserviing 
history either. It seems that it becomes relatively simple with application 
level repositories. I will hopefully be able to keep up with this list now, 
sorry if I missed anything that was already discussed.

Marcus