FindKDE4Internal.cmake and Nepomuk

[Sebastian Trüg]

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.

> If so, this is a bug fix, if not, it is a source incompatible change I'm
> afraid:
> http://techbase.kde.org/Policies/CMake_and_Source_Compatibility
>
> > I dont know if that is
> > enough since I don't really know how the whole check works. Understanding
> > it completely will take some time while I am sure there is someone
> > (Alex?) who can do it in a minute. ;)
>
> Is nepomuk the stuff in kdelibs or is it in kdesupport ?

kdelibs. I think it is the only optional lib in kdelibs.

> (I'm always confused by nepomuk, strigi and all that).

sp. Soprano and Strigi are in kdesupport. libnepomuk is in kdelibs, and the 
nepomuk services are in kdebase.

> 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.

Cheers,
Sebastian