KDE/kdelibs/cmake/modules

[Volker Krause]

On Wednesday 06 September 2006 22:34, Alexander Neundorf wrote:
> On Wednesday 06 September 2006 20:07, Alexander Neundorf wrote:
> > On Wednesday 06 September 2006 11:16, Volker Krause wrote:
> > > On Tuesday 05 September 2006 23:10, Alexander Neundorf wrote:
> > > > Hi Volker,
> > > >
> > > > On Tuesday 05 September 2006 09:50, Volker Krause wrote:
> > > > > On Monday 04 September 2006 23:32, Alexander Neundorf wrote:
> > > > > > SVN commit 580957 by neundorf:
> > > > > >
> > > > > > Remove the FORCE keyword from the various install directories,
> > > > > > which we added in Trysil. By now it should be correct in
> > > > > > everybodies cache, and without the FORCE it can now even be
> > > > > > edited again.
> > > > > >
> > > > > > Let me know if suddenly some things aren't installed correctly
> > > > > > anymore for you.
> > > > >
> > > > > There is one problem with this: If you now change the install
> > > > > prefix all those variables aren't updated, ie. they still point to
> > > > > the previous install prefix. That's why we re-added the FORCE
> > > > > option for LIB_INSTALL_DIR and added an extra LIB_SUFFIX setting.
> > > >
> > > > I tested the behaviour with the attached file, just put it in an
> > > > empty directory and run cmake on it.
> > > > I specified a different LIB_SUFFIX and all depending variables
> > > > changed as expected, both when using ccmake and when using cmake
> > > > -DLIB_SUFFIX...
> > > >
> > > > It is a direct copy from the stuff in FindKDE4Internal.cmake.
> > > > Can you please test and let me know which issues you have with this ?
> > >
> > > Well, this obviously works since the FORCE options are there. Here is
> > > an simple example to demonstrate the problem without FORCE:
> >
> > Ooops, I was *so* sure that I removed them all.
> > Very strange.
> > Ok I'll have another look
>
> Ok, now is attached what I actually wanted to attach.
> If FORCE is used, then the "calculations" are done everytime and the
> results go into the cache.
> This has the effect that if you set LIB_SUFFIX to something, it ends up in
> LIB_INSTALL_DIR, PLUGIN_INSTALL_DIR etc.
> But it has also the effect that changing e.g. EXEC_INSTALL_PREFIX is not
> possible.
> You can set it to /foo/bar/weirdo/ in ccmake, but after configuring it is
> set back to CMAKE_INSTALL_PREFIX -> due to the force. And since
> LIB_INSTALL_DIR, BIN_INSTALL_DIR etc. use EXEC_INSTALL_PREFIX, they are
> also set back to CMAKE_INSTALL_PREFIX because of the FORCE.
>
> Without FORCE chaning LIB_SUFFIX in ccmake changes nothing, because the new
> value of LIB_SUFFIX isn't FORCEd into the other variables.
> But now you are able to edit all the install locations you want and set
> them as you want.
> But if you run cmake the first time (i.e. with no CMakeCache.txt) like
> this: cmake <dir> -DLIB_SUFFIX:STRING=64
> then you get the behaviour you actually want.
>
> Yet another option would be to use
> SET(LIB_INSTALL_DIR ${EXEC_INSTALL_PREFIX}/lib${LIB_SUFFIX} )
>
> Then you can edit LIB_SUFFIX and EXEC_INSTALL_PREFIX later on and
> LIB_INSTALL_DIR will reflect the changes (since now it doesn't come from
> the cache).
> But in this case you are not able to change LIB_INSTALL_DIR to arbitrary
> locations (as it is possible with CACHE and no FORCE). I expect that then
> there will also be people which will complain.
>
> So to make it short:
> as it is now:
> specifiy LIB_SUFFIX when running cmake the first time
> after that edit every install location as you want
>
> Is that ok for you ?

If it would be just for LIB_SUFFIX, yes. But being unable to change the 
install prefix later on (without changing all of the 20+ variables using it) 
looks like too high price for being able to set them to abitrary values (can 
KDE actually handle that?). IMHO changing the install prefix is a much more 
common action, if it's not possible anymore to do that by just changing 
CMAKE_INSTALL_PREFIX eg. a warning when trying to change it might be helpful.

regards
Volker


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060907/7fac6e11/attachment.pgp