Small problem with PolkitQt

[Alexander Neundorf]

On Sunday 10 January 2010, Dario Freddi wrote:
> Sorry for the late answer, troubled life is back.
>
> On Wednesday 30 December 2009 21:38:12 Alexander Neundorf wrote:
> [..]
>
> > In general determining install locations are the responsibility of the
> >  project which is being built. I mean, if I chose to install something to
> >  $HOME/inst it shouldn't matter where PolkitQt is installed.
> >
> > What we do for the other install dirs like BIN_INSTALL_DIR etc. in
> > kdelibs is the following:
> > if the variable (e.g. KDE4_AUTH_POLICY_FILES_INSTALL_DIR) has not been
> > explicitely set, and if the current CMAKE_INSTALL_PREFIX is the same as
> > the kdelibs install prefix, then we reuse the variable (e.g.
> > KDE4_AUTH_POLICY_FILES_INSTALL_DIR) from kdelibs.
> >
> > Look for the macro _SET_FANCY() in
> > kdelibs/cmake/modules/FindKDE4Internal.cmake.
> >
> > Does this do what you want ?
>
> Unfortunately not. The problem here is that we really want to store some
> data: KAuth is backend based, and we have no knowledge at build time
> (outside KDELibs) of which backend was built, hence how to handle it.
>
> This is probably a reason why I'd put stuff in
> CreateKDELibsDependencies.cmake. I'd add two variables: one,
> KDE4_AUTH_BACKEND_NAME, carrying the name of the chosen backend, and one,
> KDE4_AUTH_POLICY_FILES_INSTALL_DIR carrying the location of the policy
> files install dir, if any (which is required unless we decide to install
> findpolkitqt*.cmake).
>
> Now, the logic for selecting the backend name is
> kdecore/auth/ConfigureChecks.cmake, where the KAUTH_BACKEND variable is
> set. Once that is done, finding out the value of
> KDE4_AUTH_POLICY_FILES_INSTALL_DIR is a breeze. The only problem I see is
> that putting straight into
> CreateKDELibsDependenciesFile.cmake set(KDE4_AUTH_BACKEND_NAME
> ${KAUTH_BACKEND}) fairly doesn't work.

I guess KAUTH_BACKEND is empty for you ?
There are I think three way you can get values from child directories up their 
parent directories:

1) put them in the cache.
This is "almost" done for KAUTH_BACKEND.
There is the following code in kdecore/auth/ConfigureChecks.cmake:

set(KAUTH_BACKEND "" CACHE STRING "Specifies the KAuth ...")
...
       if (POLKITQT_FOUND)
            set (KAUTH_BACKEND "PolkitQt")
...


The first line puts KAUTH_BACKEND in the cache if it's not already there. So 
you can access this value ("") from the toplevel.
Then, later on, there are several set(KAUTH_BACKEND ...) calls without 
the "CACHE" argument. This means they set the non-cache variable 
KAUTH_BACKEND, which hides the one from the cache, but which doesn't write 
the new value into the cache.
To actually get this value into the cache, you need to use the FORCE argument 
for set:
set( ... CACHE ... FORCE)
This will write the value into the cache no matter what's already there in the 
cache.
I guess this is what you want to do.

2) You can set a GLOBAL property anywhere in the tree, and query this property 
from anywhere else (but only after it has been set)

3) You can call set(... PARENT_SCOPE), but I think this will be messy if you 
want to get a value several levels up.


Oh, and there's a 4th one: You can leave ConfigureChecks.cmake in 
kdecore/auth/, but include it directly from kdelibs/CMakeLists.txt, so the 
variables will be directly available at the toplevel.


And I still think the install dir should be handled the same way the other 
install dirs are handled, i.e. it should take the same value as kdelibs if it 
is installed to the same prefix, it should be settable via the cache, and I 
wouldn't mind if it defaults to some other location if the 
CMAKE_INSTALL_PREFIX is different from the kdelibs location.

Alex