What to do with _set_fancy?

[Alexander Neundorf]

On Saturday, September 17, 2011 09:13:38 PM Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Friday, September 16, 2011 04:56:35 PM Stephen Kelly wrote:
> >> 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
> > 
> > I think so.
> > This feature is mostly a convenience thing, but potentially useful for
> > any project which installs files into more than one directory.
> > Then this feature makes sure that e.g. all SYSCONFIG files go into the
> > same install directory, without making it necessary to manually adjust
> > the SYSCONFIG install dir for each of the installed packages manually to
> > the same dir.
> 
> I don't know what SYSCONFIG is. Maybe it's not an important detail.

It's the /etc directory typically, so it is important.

> > And this must be "before" any framework is installed, otherwise it is not
> > guaranteed that all already installed frameworks have been installed into
> > the same directories, which is the goal of this feature.
> 
> Is it a problem that kdesupport doesn't use set fancy?

I always saw it that way that developers of stuff in kdesupport are 
responsible for their buildsystem themselves (as opposed to being inside KDE, 
see below).

> There's no guarantee
> that stuff in kdesupport has been installed into the same directories. Is
> that a problem that will be solved by this feature?
> 
> You wrote that it's a KDE only feature, but I'm still not sure I understand
> why. Is KDE alone in wanting to install things to consistent places?

Kind of, as KDE is a huge umbrella project providing a lot of convenience 
features for developers so they can be lazy and not care much about such 
issues. IOW, we have people going through different KDE projects and caring 
for the buildsystem (Coolo before CMake, now e.g. me).
 
> >> > 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?
> > 
> > Whenever you want that for some install directory the same directory is
> > used as has been used for kdelibs (in the case that you install into the
> > same prefix as kdelibs).
> > E.g. if for kdelibs LIB_INSTALL_DIR has  been manually set to lib64, all
> > other KDE libraries will be installed into lib64.
> 
> Ok. And in KDE4 times, that's not automatic, so eg, everything in
> kdesupport had to get a LIB_SUFFIX=64 in order to be correct?

Yes.
 
> I'm also confused because you said in the previous mail that it's not
> relevant to LIB_INSTALL_DIR. Or did I misunderstand?

You are right.
Maybe I simply try to explain what _set:_fancy() does exactly:

_set_fancy() has at least two features:
1) inheriting install dirs from kdelibs when installing into the same
     directory as kdelibs
I guess this is still wanted, e.g. use the same DATA_INSTALL_DIR as has been 
set for kdelibs.

2) only store the value in the cache if it has been set explicitely.

Here is a snipped from FindKDE4Internal.cmake:

_set_fancy(SHARE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}/share"
                     "Base directory for files which go to share/")
_set_fancy(DATA_INSTALL_DIR         "${SHARE_INSTALL_PREFIX}/apps"
             "The parent directory where applications can install their data")

I think I implemented this at Akademy 2006. I think at this time, when you did 
cmake -DSOME_VAR=blub, SOME_VAR was not automatically stored in the cache. 
That's why there is logic in _set_fancy() to put the value in the cache if it 
has already been set. This should not be necessary anymore, since I changed 
this in cmake while I was at Kitware in 2007 IIRC.

In the snipped above, you see that all paths are set to be absolute paths. 
There was a reason for that, it had to do with installation....
But I think this reason is not valid anymore, since I thought about changing 
it to use relative paths a few times in the last years, but didn't dare since 
it would have been easy to break something. So I just left it as it is.

In the snipped above, DATA_INSTALL_DIR is set relativ to SHARE_INSTALL_DIR, 
which is set relative to CMAKE_INSTALL_PREFIX.

If it would be 

set(SHARE_INSTALL_PREFIX "share" ... CACHE )
set(DATA_INSTALL_DIR         "${SHARE_INSTALL_PREFIX}/apps" ... CACHE )

then DATA_INSTALL_DIR would not change if SHARE_INSTALL_DIR is changed in the 
cache during a later (i.e. not the initial) cmake run, since both variable 
will be already stored in the cache, and set(... CACHE) only writes the value 
in the cache if it is not there yet.

So, these depending install locations make things harder.

Alex