Fwd: extragear/multimedia/k3b/k3bsetup

Alexander Neundorf neundorf at kde.org
Tue Nov 17 20:02:59 CET 2009


Hi,

On Monday 16 November 2009, you wrote:
> On Monday 16 November 2009 22:28:47 Alexander Neundorf wrote:
> > On Monday 16 November 2009, Michael Jansen wrote:
> > > Made a typo in CCMAIL :)
> > >
> > >
> > > SVN commit 1050113 by mjansen:
> > >
> > > Fix the includes. POLKITQT_INCLUDE_DIR already contains "PolicyKit".
> > >
> > > >From FindPolkitQt.cmake
> > >
> > >   set(POLKITQT_INCLUDE_DIR ${POLKITQT_INCLUDE_DIR}/PolicyKit/polkit-qt
> > > ${POLKITQT_INCLUDE_DIR}/PolicyKit/)
> > >
> > > >From CMakeCache.txt
> > >
> > >    POLKITQT_INCLUDE_DIR:PATH=/kde4/trunk/support/include
> > >
> > > This is confusing. But is it wrong?
> >
> > What is confusing ?
>
> A developer using FindPolicyKit.cmake wanting to know what
> POLKITQT_INCLUDE_DIR is (so he get's his includes right) will see a value
> in the cache that is not the value used to compile his code and get's his
> includes wrong.
>
> I'm currently fixing many bugs along that lines.

Cool, thanks :-)

> > If you just do SET(var value) this doesn't automatically make it into the
> > cache.
> > You need the CACHE keyword (which puts it in the cache if it's not
> > already there) or the CACHE and FORCE keywords, which puts it always in
> > the cache.
>
> Thx for the explanation. But since i'm an absolut cmake noob in that regard
> i wondered if it works caching a different value then the one we originilly
> retrieved using find_path. I have no ide how that caching works. One of
> these days i have to read up on cmakes inner workings and stop dabbling on
> the surface.

Ok. There are two levels of variables in cmake, cache variables and "normal" 
variables.
"Normal" variables hide/shadow the cache variables.
When cmake starts, it reads the cache and sets the cache variables, e.g. 
FOO_LIBRARY.
Then you can read-access the FOO_LIBRARY cache variable in cmake code:

message(STATUS "FOO_LIBRARY is ${FOO_LIBRARY}") 
...gives e.g. "/lib/libfoo.so" 

If you simply use set(), it always sets the normal, non-cache variable:

set(FOO_LIBRARY "blub")

Now you have two FOO_LIBRARY variables, the cache variable, which is 
still "/lib/libfoo.so", and the normal variable, which is "blub", and which 
hides the cache variable now.
So now
message(STATUS "FOO_LIBRARY is ${FOO_LIBRARY}") 
gives "blub".


To get something in the cache, you have to use
set(... CACHE )
This will write the given value in the cache if that variable does not yet 
exist in the cache (otherwise this would dismiss any changes which were made 
by the developer to the cache).

If you really want something to go in the cache, you have to use
set( ... CACHE FORCE)
This will always stopre the given value in the cache (and by this overwrite 
any changes which were made explicitely by the developer e.g. using cmake-gui 
or make edit_cache or ccmake).  

The find_XXX() calls store there results in the cache. First the check the 
value of the variable which they should search, e.g. FOO_LIBRARY. If the 
value is invalid (i.e. empty or contains "NOTFOUND") , they actually search 
and store the result in the cache. If the value is valid before the search, 
they don't actually search.

I hope this was somewhat clear. Let me know if not.

Alex


More information about the Kde-buildsystem mailing list