[Kde-scm-interest] Package splitting
Marcus D. Hanwell
mhanwell at kde.org
Thu Jan 28 06:59:05 CET 2010
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,
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.
More information about the Kde-scm-interest