automoc4 from kdesupport now supported for building KDE
David Faure
faure at kde.org
Wed Jun 4 23:46:53 CEST 2008
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, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the Kde-buildsystem
mailing list