rpath handling

[Matthias Clasen]

On Wed, 2010-06-23 at 22:04 -0400, Toshio Kuratomi wrote:
> On Wed, Jun 23, 2010 at 07:58:18PM -0400, Colin Walters wrote:
> > Hello internet,
> > 
> > So I lost yesterday and part of today to what I thought was a libtool
> > bug, but turned out to be an interaction with Fedora's current primary
> > recommendation for rpath handling:
> > 
> > http://fedoraproject.org/wiki/RPath_Packaging_Draft
> > 
> > The main recommendation is to use sed to reach into libtool's guts,
> > which normally works (well, until libtool changes, then we have a lot
> > of copy and paste to fix, but that's another story).  However, glib2
> > uses a program called "gtk-doc" which requires actually running an
> > uninstalled binary to extract some data from it.  This fails with the
> > Fedora rpath handling approach because the rpath is required at build
> > time.
> > 
> What is being run at build time needing which rpath in order to function?
> And is gtk-doc running something specially because this is glib2 or is it
> running things every single build?  (Back in the day, it just extracted
> things from source code comments, so I'm not sure what this new behaviour is
> doing).

Its not new. gtk-doc has always used introspection to extract
information about enums, signals, properties, etc from GObject
libraries. What is different here is that Colin is pushing for building
from git, which makes it necessary to generate the docs at rpm build
time. When building regular rpms from tarballs, we traditionally prefer
to package pre-generated docs that are included in the tarball, to avoid
multilib problems.