Small problem with PolkitQt

[Alexander Neundorf]

On Tuesday 12 January 2010, Dario Freddi wrote:
> Hello back,
>
> 2010/1/11 Alexander Neundorf <neundorf at kde.org>
>
> > 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.
>
> It is. The attached patch does exactly this, and it works. It feels to
> me a bit weirdo, though, that I have to set the docstring each and
> every time. Maybe I am missing something?

No, not really.
But putting the doc string into a variable and using this would probably be a 
very good idea.

> Also, I changed the name of KAUTH_BACKEND into KDE4_AUTH_BACKEND_NAME
> for consistency. I'll write somewhere about the change as well.
>
> > [snip]
> >
> > 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.
>
> It actually should be already so: as you can see from the patch, the
> locations are based upon CMAKE_INSTALL_PREFIX (even if this might lead
> to utter fails, which are however decently reported at build time),
> and added to the cache.

I'll have a closer look at this tomorrow.

Alex