Making writing Config.cmake files easier - updated example

[Alexander Neundorf]

On Tuesday 17 January 2012, Alexander Neundorf wrote:
> On Monday 16 January 2012, Yury G. Kudryashov wrote:
> > Alexander Neundorf wrote:
> > > On Sunday 15 January 2012, Yury G. Kudryashov wrote:
> > >> 15 January 2012 20:06:51 Alexander Neundorf written:
> > >> The only comment: there are 4 possible combinations of
> > >> cmake -DLIB_INSTALL_DIR=relative_or_absolute -
> > >> DINCLUDE_INSTALL_DIR=relative_or_absolute
> > >> It seems that your library will not be relocatable if
> > >> INCLUDE_INSTALL_DIR is set to an absolute path.
> > > 
> > > I think I can improve this a bit more, but yes, this may be a
> > > limitation, but IMO an acceptable limitation.
> > > If you want to create a relocatable package, don't set absolute paths.
> > > (I know all install dirs are absolute with kdelibs4, this will change
> > > with KDE frameworks).
> > 
> > This can be solved if you store the original prefix in Config.cmake.

I extended the set_absolute() function so that it can now also "relocate" 
absolute install dirs, it's in the ImprovedConfigDotCMakeFile branch.
But I'm actually not sure whether this is a good idea at all.
Using absolute install paths could, maybe should be interpreted as "don't 
relocate me".
I mean, this is not the only thing which has to be taken care of.
A package which contains absolute RPATHS may not be relocatable. A package 
with relative RPATHS might be relocatable.
A package may have relative install dirs but absolute RPATHs (to its own 
shared libraries). It still is not be relocatable.

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BarConfig.cmake.in
Type: text/x-matlab
Size: 2529 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20120117/8638b7e2/attachment.bin>