David Faure wrote: > On Tuesday 03 June 2008, Brad King wrote: >> 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.
The motivation behind our view is that users should be able to set CMAKE_PREFIX_PATH and have CMake find things there first. 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. >> 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 If the user specifies a custom CMAKE_PREFIX_PATH it will override what FOO says. In practice the find_library will be in a find script or something. >> 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... The idea is that that one file is found by find_package, which is extremely powerful (more powerful than pkgconfig, in fact). It also works well on Windows and OS X (with frameworks too). >>> 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 :-) We don't really want this done so it's okay if it's ugly. See above. -Brad _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem