FindNepomuk.cmake
Andreas Pakulat
apaku at gmx.de
Sun Jun 26 20:11:59 CEST 2011
On 26.06.11 19:29:10, Michael Jansen wrote:
> A short question. I just found out that kdenlive does not compile for me
> because it failed to add the SOPRANO_INCLUDE_DIR to it's build-system. The
> dependency was acquired indirect over using nepomuk.
>
> FindNepomuk checks for Soprano but does add nothing of it to it's
> NEPOMUK_<XYZ>_LIBRARIES vars and a NEPOMUK_INCLUDE_DIRS var does not exist. So
> my question is:
>
> Is the correct solution to add the soprano libs/includes to the
> NEPOMUK_*_LIBRARIES / INCLUDE_DIRS so a user of nepomuk is relieved of having
> to know nepomuks dependecies. Or must i fix kdenlives CMakeLists.txt to add
> the SOPRANO_INCLUDE_DIR (which it does not check explicit for).
The rule is that, if a library (nepomuk in this case) exposes classes,
functions etc. of one of its dependencies in its public API then it
should add those dependencies to the LINK_INTERFACES_LIBRARIES property
of its targets during build and ideally use imported-targets in its
FindXXX.cmake (or XXXConfig.cmake) file so that the same can be done
there.
If not using imported targets, the LIBRARIES variables usually only
contain the libraries that the corresponding project provides itself,
not the dependencies of it. So for linking-errors a fix in the app needs
to be done.
For the include-dirs I'd check with the Nepomuk authors wether its
actually possible to use nepomuk without soprano. If not, then I'd
probably add the soprano includes to the _DIRS variable, otherwise fix
the application. Reasoning is to keep the list of includes rather clean,
if there are ways to use nepomuk without ever knowing it uses soprano.
> It seems btw that kdenlive does not need to add the soprano libraries explicit
> here. Most likely because it does not use any Soprano stuff in its own code.
If the public API of nepomuk exposes Soprano and the code uses that,
then it also needs to link against soprano. However older
linkers/distro's allowed transitive linking, i.e. if libA links to libB
then appA linking to libA automatically links against libB.
However the trend these days is towards getting less transitive linking.
Andreas
More information about the Kde-buildsystem
mailing list