automoc4 from kdesupport now supported for building KDE

[David Faure]

On Tuesday 03 June 2008, Brad King wrote:
> David Faure wrote:
> >> From "cmake --help-command find_library":
> >> If NO_DEFAULT_PATH is specified, then no additional paths are added to the search.
> > 
> > This is in fact the reason why now kdelibs can't find phonon.
> > 
> >    find_library(PHONON_LIBRARY NAMES phonon PATHS ${KDE4_LIB_INSTALL_DIR} ${KDE4_LIB_DIR} ${CMAKE_SYSTEM_LIBRARY_PATH} ${QT_LIBRARY_DIR} ${LIB_INSTALL_DIR} NO_DEFAULT_PATH)
> > 
> > So -DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk;/d/kde/inst/phonon (correct syntax, right?)
> > doesn't work, because of the NO_DEFAULT_PATH. The reason why use NO_DEFAULT_PATH almost everywhere
> > is simple: without it, libs in /usr/lib are preferred over those in the PATHS specified to find_library.
> 
> The issue here is that we (cmake devs) view the PATHS argument as a list
> of last resort paths (e.g. hard-coding c:/Python25), not preferred
> paths.  There are a whole bunch of user-controlled places that are
> searched before /usr/lib.

This assumes that users specify all their lib locations as arguments. It's nice to be able
to do that, but ideally things should just "work out of the box", that's the whole point
of that list of paths -- to try and autodetect where the stuff is installed, to save the
user some work.

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

> When CMake 2.6 is required everything should switch to using the
> export/import feature:
> 
> http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets
> 
> along with the full power of find_package and this issue should go away
> completely.  CMake will then just load a file that tells it exactly
> where libraries are located (i.e. full paths to the library files).

... as long as it finds that file in the first place, so I'm not sure this changes anything, in fact.
Autodetection wanted when possible, manual setting of own prefix otherwise...

> > Is there a way to get "check those paths first, then fallback to the default paths" behavior, without duplicating
> > all the default paths in the find_library call?
> 
> Yes, and it's mentioned in the find_library documentation:
> 
>   find_library(FOO_LIBRARY NAMES foo
>                PATHS ${PATH1} ${PATH2} ... NO_DEFAULT_PATH)
>   find_library(FOO_LIBRARY NAMES foo)

Ah, right, I remember seeing this. It looks ugly and redundant, but ok :-)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).