Small problem with PolkitQt

Dario Freddi drf54321 at gmail.com
Sat Jan 23 15:35:38 CET 2010


Sorry for the delay. Here goes.

On Saturday 16 January 2010 19:27:19 Alexander Neundorf wrote:
> On Thursday 14 January 2010, Dario Freddi wrote:
> > On Wednesday 13 January 2010 20:21:50 Alexander Neundorf wrote:
> 
> ...
> 
> > > [...]
> > >
> > > 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.
> 
> Hmm, then at least write a
> set(KDE4_AUTH_POLICY_FILES_INSTALL_DIR  ... CACHE )
> in the KDELibsDependencies.file, this way it can be changed via the cache
> later on.
> 
> > > > 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?
> 
> Yes.
> 
> Alex
> 

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

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kauth_patch.diff
Type: text/x-patch
Size: 7914 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20100123/b167a9c6/attachment.diff 
-------------- 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/20100123/b167a9c6/attachment.sig 


More information about the Kde-buildsystem mailing list