What to do with _set_fancy?

[Stephen Kelly]

Alexander Neundorf wrote:

> On Tuesday, September 13, 2011 08:27:27 PM Stephen Kelly wrote:
>> Hi,
>> 
>> FindKDE4Internal has a macro _set_fancy which does some messing about
>> with the cmake cache and variables one might set (particularly paths).
>> 
>> * Where does this feature belong?
> 
> It is very special.
> For some of the install destinations, it shouldn't be necessary at all.
> E.g. for the LIB_INSTALL_DIR and for INCLUDE_INSTALL_DIR, these two don't
> even have to be in the cache, so a simple set should do for them (as
> discussed in Randa). This has the positive effect that it is much easier
> to find the include and lib directory from a Config.cmake file.
> 
> For some, it needs to be in the cache, e.g. the /etc-dir, SYSCONFIG I
> think.
> 
> Additionally, it has the additional logic, that if kdelibs has already
> been
> installed to the current  CMAKE_INSTALL_PREFIX, then it reuses all the
> install dirs from that kdelibs installation.
> This was a special request from some of our developers.

Does this mean anything in the context of frameworks? If we consider that 
'kdelibs' is an integration thing (containing KApplication, cmake macros etc  
as described on kcd) which depends on the frameworks, should the install 
location of that ('kdelibs') be found?

> 
> Also,  we always use full paths for install locations, which is not a good
> thing, since it creates problems on Windows. So this should be changed for
> kf5.

Already done in ECMQtFramework.cmake.

> 
>> * Is it working around a cmake deficiency?
> 
> Not really.
> 
>> * Does cmake need to be fixed?
> 
> Since 2.8.4 or 2.8.5 cmake comes with a GNUInstallDirs.cmake, which
> defines a set of install locations as cache variables.
> Maybe we should use that instead ?

I'm not sure. I read the documentation and I can't tell if it would make the 
patch I added to kauth obsolete. Can you review the patch 
(ba1ed1db5ecd97db70eb820233e01498303d7af5) and find out? 

I also don't know why kauth uses the macro. When should the macro be used? 
Should it always be used for plugin directories?

> It puts all the install locations in the cache (including e.g. the one for
> headers, which IMO should not be modifiable).
> This also allows to use absolute paths in the install locations, which,
> for most locations, we shouldn't do.
> 
> And of course, it doesn't and can't have the special logic for reusing the
> install locations if a kdelibs has been found in the same location.

This is something of concern for 'KDE Applications', right? Not frameworks 
in general?

> 
> So, I'm not sure what to do.
> IMO, this is something KDE-specific, so it should/could be in some KDE-
> specific component, and if some software uses this component, it becomes a
> KDE software.
> Then we could just keep it as it is, including the set of install dirs
> which are defined in FindKDE4Internal.cmake.
> (similar to how we decide which compiler flags to use etc.)
> 

It seems like this is solvable by having an integration level called 
'kdelibs' which depends on frameworks which contains stuff like this.

Steve.