automoc4 from kdesupport now supported for building KDE
Brad King
brad.king at kitware.com
Tue Jun 3 21:18:36 CEST 2008
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.
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?
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).
> 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)
-Brad
More information about the Kde-buildsystem
mailing list