On Wednesday 04 June 2008, Brad King wrote: > David Faure wrote: > > On Wednesday 04 June 2008, Brad King wrote: > >> 1.) CMAKE_PREFIX_PATH from environment > >> 2.) CMAKE_PREFIX_PATH from cmake variable > > Interesting; shouldn't the cmake variable (e.g. specified on the command > > line) > > be preferred over the environment variable (which could be set in .bashrc, > > i.e. > > it's less specific and less explicit than cmake -DCMAKE_PREFIX_PATH=?). > > It's a tough call. The user could also do > > CMAKE_PREFIX_PATH=... cmake ../src > > for a one-shot tweak, or the project author could write > > set(CMAKE_PREFIX_PATH ...)
Hehe, indeed. But both are very uncommon (everyone uses -D syntax when calling cmake, and a project author wouldn't know what to set CMAKE_PREFIX_PATH to IMHO, or only as a result of a previous autodetection, which itself would have to follow the rules of reading the user's settings first :) ) > which is even less specific. However, I think the common use cases > would be the env var in a .bashrc and the cmake var in the cache or on > the command line. Additionally, a build script could set the cache > variable to make it work independently of the user's environment if it > were preferred. This argues in favor of switching the order. > > So, the overall preferred order for specificity is > > 1.) current build tree (CMAKE_PREFIX_PATH var) > 2.) user environment (CMAKE_PREFIX_PATH env) > 3.) current project source (PATHS option) > 4.) system environment (PATH env) > 5.) platform conventions (CMAKE_SYSTEM_PREFIX_PATH) > > Does this make sense? Indeed it does. > Making this order work would require projects to avoid setting the > CMAKE_PREFIX_PATH variable and instead use the PATHS option. This seems > to be what everyone expects anyway. Yes, it makes the syntax much nicer, compared to storing, setting, and restoring CMAKE_PREFIX_PATH. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
