Re: builddirs (was Re: ATK dependency added to GTK+)

[Erik Walthinsen <omega temple-baptist com>]

On 3 May 2001, Havoc Pennington wrote:

> Couldn't you just generate a separate uninstalled .pc file for use
> with this case, which contained builddir hardcoded in the .pc file?
>
> i.e. you would generate "gtk+-2.0-builddir.pc" from
> "gtk+-2.0-builddir.pc.in" and then you would pass that .pc file to
> pkg-config.
True.  Then the autoconf macro can use one or the other (assuming there's
a standard name) if you give it a builddir path on the configure cmdline.

> Owen points out that there's an issue with libtool wanting relative
> paths to the .la file, which would maybe involve a pseudo-variable for
> "directory containing .pc file" so you would have in the .pc file:
>
>  Libs: ${pcfiledir}/../../libfoo.la
>
> where pcfiledir is the PKG_CONFIG_PATH entry we found the .pc file in,
> NOT the absolute dir name it's in.
Hmm, I haven't played with pkg-config much yet.  But having the
${pcfiledir} variable would make it that much easier to make these
builddirs 'relocatable', i.e. the paths are based on the actual current
location of the builddir.

An issue that definitely is relevant though is that the ldflags would
probably have a libtool archive listed by path, which doesn't work at all
if you're not using libtool.  How can that be worked around?  Do we assume
that if $USING_LIBTOOL (or somesuch) isn't defined, pkg-config has to put
in '-static -Lpath -lname' instead of 'path/libname.la'?  Do we even want
to solve that problem?

      Erik Walthinsen <omega temple-baptist com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_