Git migration status (Was: Re: Where is kmix hidden?)
neundorf at kde.org
Mon Aug 22 20:54:12 BST 2011
On Monday 22 August 2011, Jeremy Whiting wrote:
> On Sun, Aug 21, 2011 at 5:06 PM, Lukas Appelhans <l.appelhans at gmx.de> wrote:
> > On Sunday 21 August 2011 23:13:30 George Goldberg wrote:
> > > On 21 August 2011 14:05, Lukas Appelhans <l.appelhans at gmx.de> wrote:
> > > > Hey!
> > > >
> > > > Cool... I see you go for a split up of kdenetwork (makes sense imo).
> > >
> > > Yup. Definitely.
> > >
> > > > The problem I see at the moment you have to build all applications
> > > > together in kdenetwork, otherwise they fail to compile. So this is a
> > > > first thing which needs to change.
> > >
> > > Others have already answered this - some of the apps already build
> > > standalone, others will need a bit of cmake modifications first.
> > Yes. I will see what I can do about that in the next weeks. :)
> > > > What is missing are tags and branches right?
> > >
> > > Yes. I think I've got the whole trunk history sorted iirc. Haven't
> > > done the tags and branches though.
> > Okay.
> It's not needed to make all the tags and branches build standalone and
And it is also relatively hard to get this right.
I have a slightly bad feeling when I read here posts that some modules have
been tweaked so they can be built both ways, because to do this, you have to
be aware of quite some details in cmake behaviour, like how cache variables
behave, how targets, libraries and library search paths are handled, etc.
Currently I don't have the time to go through all (...and we have _many_ now)
git repositories and check whether they are doing it the right way.
I recommend that the git repos build standalone, and do find_package() for
All installed libraries should export their targets and install a cmake
To build the modules as they were, a tool like kdesrc-build, buildtool or KDE
superbuild (https://projects.kde.org/projects/kde/superbuild) should be used.
More information about the kde-core-devel