Small problem with PolkitQt

[Dario Freddi]

On Wednesday 13 January 2010 20:21:50 Alexander Neundorf wrote:
> [...]
> 
> It's a good idea to put this into the cache, but please put it in the cache
> without ${CMAKE_INSTALL_PREFIX}. If you do it as it is now, later changes
>  to CMAKE_INSTALL_PREFIX in the cache will have no effect on
> POLKITQT-1_POLICY_FILES_INSTALL_DIR anymore, since this will then be
>  already in the cache. So put it without that in the cache, just as a
>  relative path ("share/polkit-1/actions").
> 
> I know we put the full path of the install dirs in the cache for KDEs
>  install dirs, but first, I'm thinking about changing this, since I think
>  it is not necessary (but not before 4.4.0 is out), and second, we only put
>  it in the cache if it has been explicitely set to some custom value.
> 
> So, please put it in the cache without the prefix. If somebody wants a
> different absolute path, he can still change it to an absolute path in the
> cache.
> 
> Same comments for FindPolkitQt.cmake.

Roger that.

> 
> [...]
> 
> How KDE4_AUTH_POLICY_FILES_INSTALL_DIR is not ok.
> The information coming from the KDELibsDependencies.cmake file, i.e.
>  written by CreateKDELibsDependenciesFile.cmake, gives information about
>  the kdelibs which is installed and which has been found. They are no cache
>  variables so they cannot be changed by the user later on who builds
>  against kdelibs.
> 
> So KDE4_AUTH_POLICY_FILES_INSTALL_DIR is the variable which tells us where
> kdelibs installed its policy files to.
> OTOH the project which uses kdelibs is free to install its files to any
>  other location.
> The locations recommended for use by KDE (FindKDE4Internal.cmake) are the
> FOO_INSTALL_DIR variables from FindKDE4Internal.cmake.
> So there you should add a AUTH_POLICY_FILES_INSTALL_DIR variable. I would
> suggest that this should be handled the same way as the other INSTALL_DIR
> variables.
> This would mean if you build foo against kdelibs and install it to the same
> location, AUTH_POLICY_FILES_INSTALL_DIR will point to
> KDE4_AUTH_POLICY_FILES_INSTALL_DIR.
> But if you install it somewhere else, this will be relative to the new
> CMAKE_INSTALL_PREFIX. And if you then set it via -D or write a value you
>  want into the cache, you can point it just anyway.
> Would this be ok ?
> If not, how should it behave ?

Basically, KDE4_AUTH_POLICY_FILES_INSTALL_DIR should be a proxy to 
POLKITQT*_POLICY_FILES_INSTALL_DIR (and eventual future backends), for the 
sake of not installing the Find files and finding the package everytime a 
component using KAuth is built. I don't know if what you suggested would work 
that out.

> 
> > Index: kdecore/auth/ConfigureChecks.cmake
> > ===================================================================
> > --- kdecore/auth/ConfigureChecks.cmake	(revisione 1072643)
> > +++ kdecore/auth/ConfigureChecks.cmake	(copia locale)
> > @@ -1,28 +1,34 @@
> >  ####### checks for kdecore/kauth ###############
> 
> How about setting the non-cache KAUTH_BACKEND variable in all the branches
>  and do a
> set(KDE4_KAUTH_BACKEND_NAME ${KAUTH_BACKEND} ... CACHE ... )
> just once at the end ?

Would it work if the user set KDE4_AUTH_BACKEND_NAME explicitely?

> 
> > Index: kdecore/CMakeLists.txt
> > ===================================================================
> > --- kdecore/CMakeLists.txt	(revisione 1072643)
> > +++ kdecore/CMakeLists.txt	(copia locale)
> 
> Looks ok I'd say.
> 
> Alex
> 

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20100114/c43ebc9f/attachment.sig