automoc4 from kdesupport now supported for building KDE

Andreas Pakulat apaku at gmx.de
Wed Jun 4 14:15:09 CEST 2008


On 04.06.08 13:35:30, David Faure wrote:
> On Tuesday 03 June 2008, Brad King wrote:
> > David Faure wrote:
> > Currently the 
> > only way to override what the NO_DEFAULT_PATH stuff finds is to set the
> > result variable in the cache by hand for each and every library.  If you
> > (as a project dev) want to look in a set of default locations on the
> > users' behalf, they should be added to the search path variables by the
> > project.  Then none of the find_* commands needs special arguments, only
> > one call to each is needed, and users can override things easily.
> 
> But that means modifying global variables, i.e. affecting all other calls to find_library?
> This doesn't sound right. When looking for libbz2 we surely don't want to look into 
> ${KDE4_LIB_INSTALL_DIR} ${KDE4_LIB_DIR} ${QT_LIBRARY_DIR} ...

Well, you can first add them and then remove them again.

> > >> If you have variables like KDE4_LIB_INSTALL_DIR that are supposed to
> > >> tell you where to find the library, why do you need to search for it in
> > >> default paths at all?
> > > 
> > > Because those are just hints. Maybe phonon is in the kde install dir, but maybe it has
> > > been installed into its own prefix instead. In the first case it should be autodetected,
> > > while in the latter case it's normal that the user has to specify a prefix -- but that doesn't
> > > work because of NO_DEFAULT_PATH (which is only there so that the autodetection
> > > prefers KDE4_LIB_INSTALL_DIR over /usr/lib, not to prevent users from setting the right
> > > path manually!).
> > 
> > Okay, so follow the above advice:
> > 
> >   find_package(FOO REQUIRED)
> > 
> >   # Foo tells me where I might find other stuff.
> >   list(APPEND CMAKE_PREFIX_PATH ${FOO_INSTALL_PREFIX})
> > 
> >   find_library(BAR_LIBRARY NAMES bar)
> >   # tada!  BAR_LIBRARY is found under <foo-prefix>/lib
> 
> Yes. However this means not using NO_DEFAULT_PATH, so this brings up this orthogonal issue:
> 
> Imagine I have a /usr/lib/libphonon.so from kubuntu (so it's old, and was compiled in release mode),
> and I compile my own libphonon.so into my own prefix (say /opt/phonon/lib/libphonon.so or whatever).
> IIRC a call to find_library() would prefer the one in /usr/lib/libphonon.so even when doing
> find_library(PHONON_LIBRARY NAMES phonon PATHS /opt/phonon/lib)
> because the system paths are checked first (right? I hope I don't remember wrongly).

Right, but with that call you could set CMAKE_PREFIX_PATH and have your
phonon in /opt found.

> Right Alex? This is the reason for the NO_DEFAULT_PATH in FindPhonon? Or is the reason
> rather that you wanted CMAKE_SYSTEM_LIBRARY_PATH to have more priority than qt's [old] phonon?
> (but that's a tough choice, they could both be too old :)
> 
> Removing NO_DEFAULT_PATH fixes my problem (phonon is found when setting CMAKE_PREFIX_PATH correctly)
> OK about this patch, Alex?

No, thats wrong, it breaks when one has phonon in /usr/lib and also in
install dir, but the latter one should be used. You should add a second
call to find_library without NO_DEFAULT_PATH after the first one. That
uses phonon from KDE paths+CMAKE_SYSTEM_LIBRARY_PATH+install dir if
available and else uses the one that it finds in the default paths,
including CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH variables.

Andreas

-- 
You're growing out of some of your problems, but there are others that
you're growing into.


More information about the Kde-buildsystem mailing list