FindKDE4Internal.cmake and Nepomuk

Sebastian Trüg trueg at kde.org
Tue Apr 28 23:22:13 CEST 2009


On Tuesday 28 April 2009 23:10:28 Alexander Neundorf wrote:
> On Tuesday 28 April 2009, Sebastian Trüg wrote:
> > On Tuesday 28 April 2009 20:22:33 Alexander Neundorf wrote:
> > > On Tuesday 28 April 2009, Sebastian Trüg wrote:
> > > > Currently we have a separate test for Nepomuk in kdebase and other
> > > > places. I think that should be moved into the standard kde finding
> > > > cmake file. Can someone help with that?
> > > >
> > > > I already commited a small change but it mostly removes the
> > > > non-existing kmetadata lib
> > >
> > > Did it exist at some point in time or was it always empty ?
> >
> > it existed for a brief period before 4.0.
> >
> > > > and renames knepomuk to nepomuk.
> > >
> > > Oh.
> > > The library is also named "nepomuk" instead of "knepomuk". Was there
> > > a "knepomuk" library at some point ?
> >
> > same as with kmetadata. renamed before 4.0
> >
> > > Does that mean that KDE4_KNEPOMUK_LIBS was actually always empty ?
> >
> > yes.
>
> I guess then it should be ok.

So... can you help me here a bit?
Actually Nepomuk has Soprano as dependency. If that is not there it will not 
be compiled. Can that check be put into FindKDE?

> ...
>
> > > Also, we have since a few weeks a generally agreed commit policy for
> > > kdelibs/cmake/modules/:
> > > http://techbase.kde.org/Policies/CMake_Commit_Policy
> > >
> > > I guess I should add a point on removing and renaming stuff (actually
> > > this is part of source compatibility).
> >
> > sorry if I broke a policy. I did it since both knepomuk and kmetadata
> > never existed in a final kde release.
>
> If they didn't exist you didn't break it :-)
> Removing variables which were always empty is ok (since they will still be
> empty when used).
>
> Alex



More information about the Kde-buildsystem mailing list