[Kde-pim] Re: Using KDE branches with git
Sebastian Kügler
sebas at kde.org
Mon Jan 24 14:46:28 GMT 2011
Hey David,
On Monday, January 24, 2011 15:03:39 David Jarvie wrote:
> What is the best way to organise trunk and other KDE branches in local git
> clones? I'll use the example of kdepim trunk and 4.4, for which I want to
> maintain builds of each. Presumably if I create a local branch to mirror
> the remote 4.4 branch in the same local git repository as trunk, whenever
> I switch between trunk and 4.4 I'll have to rebuild kdepim completely
> whenever I want to build anything. That would suggest that the best
> practical way is to have separate local repositories for trunk and 4.4, so
> that switching branches doesn't force a rebuild.
>
> If not, how can I avoid having to completely rebuild every time I switch
> branches?
>
> This question also has relevance to local major feature branches, which
> also tend to trigger significant rebuilds when switching branches.
What seems to work is using separate environments and installations pathes,
roughly:
- when switching branches set your
KDE_DIRS="/home/user/kde/branch-y/install:/home/user/kde/install"
or
KDE_DIRS="/home/user/kde/branch-y/install:/home/user/kde/install"
depending on your branch.
- Set your installation path to one of the 'branch overlays'
- keep branches in /home/user/kde/src/branch-x and /home/user/kde/src/branch-x
(git clone should use hardlinks for this, so it's fairly efficient), cmakekde
will create separate build dirs, which you can keep
- Possibly change your $KDEHOME if you want to use separate configurations
(might be useful switching back and forth, though kmail2 is -- correct me if
I'm wrong -- built with switching back ot kmail1 config in mind).
You might get away with the same installation path for both branches, but it's
risky since installed file from branch-x might not be in branch-y, and could
cause BIC issue4s if they're still read (think a newer plugin which turns
stale in an older version but gets loaded).
This solution is a bit fiddly to set up, but it should be able to save your
long rebuild, at the cost of diskspace. It also makes it less costly to do
clean installs for those components, since it's easier to uninstall (just rm -
rf and re-create your install pathes).
Not sure if there's a better solution to this =)
Cheers,
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list