Small problem with PolkitQt

[Alexander Neundorf]

On Sunday 24 January 2010, Dario Freddi wrote:
> On Saturday 23 January 2010 20:58:02 you wrote:
> > On Saturday 23 January 2010, Dario Freddi wrote:
> > > Sorry for the delay. Here goes.
> >
> > --- kdecore/auth/ConfigureChecks.cmake	(revisione 1079059)
> > +++ kdecore/auth/ConfigureChecks.cmake	(copia locale)
> > @@ -1,8 +1,11 @@
> >  ####### checks for kdecore/kauth ###############
> >
> > -set(KAUTH_BACKEND "" CACHE STRING "Specifies the KAuth backend to build.
> > Current available options are
> > +set(KDE4_AUTH_BACKEND_NAME "" CACHE STRING "Specifies the KAuth backend
> > to build. Current available options are
> >                                     PolkitQt, PolkitQt-1, Fake, Apple.
> > Not setting this variable will build the most
> >                                     appropriate backend for your system")
> > +
> > +set(KAUTH_BACKEND ${KDE4_AUTH_BACKEND_NAME})
> > +
> > ...
> > @@ -79,12 +84,20 @@
> >      endif (KAUTH_BACKEND STREQUAL "POLKITQT-1")
> >  endif(NOT KAUTH_BACKEND)
> >
> > -# Add the correct libraries depending on the backend
> > -if(KAUTH_BACKEND STREQUAL "OSX")
> > +set(KDE4_AUTH_BACKEND_NAME ${KAUTH_BACKEND} CACHE STRING "Specifies the
> >  KAuth backend to build. Current available options are
> > +                                   PolkitQt, PolkitQt-1, Fake, Apple.
> > Not setting this variable will build the most
> > +                                   appropriate backend for your system")
> > +
> >
> >
> > Why do you set KDE4_KAUTH_BACKEND_NAME twice, once at the beginning and
> >  once at the end ?
> > The first one puts it already in the cache. If it is then already in the
> > cache, the second one does nothing.
>
> That's because after the user sets explicitely the backend, a check is
> performed to see if his choice is acceptable. The chain is
>
> 1 - The user inserts a backend name, "blablabla"
> 2 - The build system checks if the chosen backend is actually available
> 3 - If not, the build system falls back to another one.
>
> I thought that could have fixed this problem, is it just enough to put the
> cached variable at the end?

Ah, ok.
set(FOO " bar" ... CACHE) behaves as follows:

If "FOO" is not in the cache, it is written in the cache with the value "bar" 
(this happens during the first call in the first run).

If FOO is already in the cache, set( ... CACHE ) basically does nothing, it 
doesn't change the value in the cache.

So, your first call basically says "put this value in the cache if it's not 
there yet"
The second call basically does nothing.

If you want to change the value of a variable which already is in the cache, 
you need to add the "FORCE" option to the set() command.

Alex