kdesupport/decibel

[Alexander Neundorf]

On Saturday 08 November 2008, Dominik Haumann wrote:
> Please CC me, as I'm not subscribed to kde-buildsystem.
>
> On Saturday 08 November 2008, Dominik Haumann wrote:
> > SVN commit 881692 by dhaumann:
> >
> > fix building Decibel as submodule of kdesupport
>
> [...]
>
> > - use FORCE behind the SET(...) functions in order to set the variables
> >   correctly (previously, INCLUDE_INSTALL_DIR was reused from qimageblitz
> >   so that the Decibel includes were copied to the qimageblitz folder)
>
> I really wonder whether this "FORCE" is the right way to go. Comments are
> appreciated.

You are right, it is not.
This is how set() behaves:

set(var1 13) 
This results in a variable "var1" being set unconditionally to 13. If there 
was already a variable with the same name in the cache, the one from the 
cache is shadowed by this one.

set(var2 17 ... CACHE ...) 
If var2 is already in the cache, nothing is changed, it keeps its value from 
the cache. If var2 is not yet in the cache (i.e. usually during the first 
cmake run), var2 is set to 17 and this goes into the cache.
The value in the cache can be changed by editing CMakeCache.txt, or "make 
edit_cache", or running ccmake or running cmake-gui.

set(var3 23 ... CACHE FORCE)
No matter whether var3 was already in the cache or not, this value goes into 
the cache. This makes editing the cache manually impossible, since the value 
in the cache will always be overwritten with this call.

The 
_set_fancy(INCLUDE_INSTALL_DIR  "${CMAKE_INSTALL_PREFIX}/include"  )
has the following purpose:

if no special INCLUDE_INSTALL_DIR is given by the user (e.g. via -D...) or via 
cmake-gui, it will be set to ${CMAKE_INSTALL_PREFIX}/include . This is not 
saved in the cache at all. 
So if later one somebody changes CMAKE_INSTALL_PREFIX, INCLUDE_INSTALL_DIR 
will still be "calculated" relative to the new CMAKE_INSTALL_PREFIX.

If somebody wants a different INCLUDE_INSTALL_DIR, this is also possible. Then 
he must specify it (e.g. -D...). In this case this value will be saved in the 
cache, and thus become independent from CMAKE_INSTALL_PREFIX (i.e. if 
CMAKE_INSTALL_PREFIX is changed in a later run, this doesn't affect 
INCLUDE_INSTALL_DIR anymore, which should be ok, since the user has set it 
explicitely to some other location). If the user then wants to change 
INCLUDE_INSTALL_DIR, he has to edit the cache.

So what about kdesupport ?
One thing which was bad (for a project in kdesupport) was that qimageblitz was 
setting INCLUDE_INSTALL_DIR to include/qimageblitz/ instead of just include/. 
I changed that now.

Which behaviour do we want ?
If each project is built separately, each one can be installed to some 
differebnt location. No matter how you do it, there shouldn't be a problem 
with this.
I think a simple
set(INCLUDE_INSTALL_DIR include) 
should be good enough.
If you want to be able to set it to custom locations, it must be in the cache.
Then put it in the cache, with or without CMAKE_INSTALL_PREFIX prefixed. I 
don't see a need to FORCE it into the cache.

I would say supporting different INCLUDE_INSTALL_DIRs for the different 
projects within kdesupport when built at once all within kdesupport doesn't 
have to be supported. If you want them to be installed to different 
directories, built these projects separately.
(the one who messed this up was qimageblitz by forcing its destination into 
the cache).

Alex