What to do with _set_fancy?

Mon Sep 19 07:11:57 UTC 2011

On Sunday 18 September 2011 14:28:11 Alexander Neundorf wrote:
> 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.

definitely

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

this is necessary since the install locations depend on each other, as your 
example below shows. Updating SHARE_INSTALL_PREFIX later on would not also 
update DATA_INSTALL_DIR if that's already cached I think (at least it wasn't 
back then).

> 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. 

right, and I was the one asking for it :)

> 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.

That was definitely one of the reasons for it I think, unfortunately I don't 
remember all the details anymore. The only install location I would possibly 
have changed back then was the one for libs, adding the "64" suffix, which 
IIRC wasn't supported automatically yet.

> 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....

until very recently I was believing that install paths have to be absolute, 
maybe others were working with the same assumption ;)

> 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
> _______________________________________________
> Kde-buildsystem mailing list
> Kde-buildsystem at kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110919/e4452b46/attachment-0001.sig>