cmake linking to old libraries. Bug or feature? (was: Re: KDE/kdebase/workspace/plasma/dataengines)

[Andreas Pakulat]

On 08.05.09 16:12:07, Thiago Macieira wrote:
> Em Sexta-feira 08 Maio 2009, às 14:41:01, Thiago Macieira escreveu:
> > Em Quinta-feira 07 Maio 2009, às 17:50:55, Sebastian Kügler escreveu:
> > > SVN commit 964889 by sebas:
> > >
> > > Add Akonadi libs
> > >
> > > This should resolve the linking problems thiago got. Thiago, can you
> > > confirm?
> >
> > No, sorry, still not working.
> >
> > You're linking to ${KDE4_AKONADI_LIBS} but that variable is not defined
> > anywhere. I've just updated and rebuilt Akonadi and I don't see that
> > anywhere.
> >
> > A full grep of kdesupport, kdelibs, kdepimlibs and kdebase yields only two
> > results for that string and they're both acceors (not settings it).
> 
> Actually, I found where that variable is defined. It took some help from the 
> folks in #kontact to find it: it's defined in the KdepimLibsConfig.cmake, by way 
> of a macro. That's why my grep didn't turn it up.
> 
> So it appears that the variable is properly defined after all:
> message("Here's akonadi: " ${KDE4_AKONADI_LIBS})
> Here's akonadi: KDEPIMLibs__akonadi-kde
> 
> That's the correct value, according to the developers (that surprised me).
> 
> So the problem had to be somewhere else. After searching a bit, I found that 
> the link line to the dataengine was:
> 
> g++ [...] -o ../../../../lib/plasma_engine_akonadi.so [...] 
> /home/tmacieir/KDE-4.3/lib/libakonadi-kde.so.4.2.0
> 
> So it was linking to the older library found (I had newer versions). Since 
> none of the find_package or macro_optional_find_package for kdepimlibs had the 
> version number, can we say it's a feature to link to the lowest version found? 
> I.e., is this intentional so that we catch requirements for later features?
> 
> 
> I tried to write in 
> kdebase/workspace/plasma/dataengines/akonadi/CMakeLists.txt:
> 	find_package(KdepimLibs 4.3 REQUIRED)
> 
> and that didn't work. I did have the "4.3.0" version installed from an earlier 
> build, before it was removed. So another question: if a later dependency 
> requires a newer version than a previous dependency, does cmake use the most 
> constraining requirement? I would be surprised if it did, but it would be 
> nice.
 
> In any case, after changing 
> kdebase/workspace/plasma/dataengines/CMakeLists.txt to say:
> 	macro_optional_find_package(KdepimLibs 4.2.85)
> things started working. I have committed that fix.

I'm not sure I fully understand the problem (except that cmake seems to
have used the wrong KDEPIMLibsConfig.cmake from the wrong directory). But
unless I'm mistaken, CMake simply takes the first such XXXConfig.cmake file
that matches the search criteria, i.e. in this case is in
<prefix>/lib/cmake/XXX*/ and the version number fits.

> Then I deleted the the lib/cmake/KdepimLibs-4.3.0/ directory from my KDE 4 
> installation and things started working without any version number at all (the 
> code before my commit). I can't explain why. But this is a surprise factor and 
> could be a bug.

Not if you've read man cmake :) The find_package section explains how cmake
finds packages if in the config-mode (the one that searches in
lib/cmake/<package>/ for a <package>Config.cmake). It simply searches for
<package>*/<package>Config.cmake and then runs <package>ConfigVersion.cmake
to let the module check for version compatibility. If it finds a compatible
one, then it takes that one.

Andreas

-- 
You will be married within a year.