automoc4 from kdesupport now supported for building KDE

Brad King brad.king at kitware.com
Wed Jun 4 19:33:34 CEST 2008


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 ...)

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?

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.

-Brad


More information about the Kde-buildsystem mailing list