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