On Tue, 27 Apr 2004 12:19:07 -0700 (PDT)
"Jeremy C. Reed" <reed@reedmedia.net> wrote:

> > The only solution I see to this is to define a global environment variable,
> > say VIEWBASE, that the user can set to point to their view (in general,
> > /usr/pkg).  We'd have to modify several packages to honour it, but it could
> > be good to have, I think.
> 
> That seems like a good idea.
> 
> But before someone modifies the pkg-config tool to use it, should I use
> the following?
> 
> +CONFIGURE_ARGS+=       --libdir=${VIEWBASE}/lib
> 
> (This VIEWBASE is different from the shell environment
> variable that is not in use yet.)

It's the same problem.  If I'm not wrong, VIEWBASE points to the default view,
i.e., /usr/pkg.  So the package will end up with a hardcoded path to
/usr/pkg/lib/pkgconfig, too.

> What other packages may need ot have a global environment variable?

Lots.  For example, gtk2 (which looks for plugins and themes in specific
directories used by many packages), gstreamer, xmms, xmlcatmgr,
scrollkeeper, perl... etc, etc, etc.

> Now that I think about it, maybe a global environment variable is not
> needed. If the user is using a different view, would that mean they are
> also using a different pkg-config tool?

They are using the same binary but through different symlinks.  With a single
binary, you have a single hardcoded path, so the problem remains :-/

What I propose is having /usr/pkg/bin/pkg-config be a shell script (instead of
a symlink), which simply does:

#!/bin/sh
VIEWBASE=/usr/pkg; export VIEWBASE
/usr/pkg/packages/pkgconfig-0.15.0/bin/pkg-config "$@"

This script should be created by linkfarm(1) or whatever, but only when
linking a package from its depot directory into its view (so it knows which
value to put in the VIEWBASE variable).  If you create another view, the
program could create another shell script with a different value for the
variable, and execute the same binary.

Obviously, we'd have to patch all those programs to recognize the VIEWBASE
variable at runtime (falling back to their depot directory if it's not set,
I think).  The problem is that those (trivial) patches won't be accepted by
the upstream authors, probably, unless we try very hard to convince them... :P

Anyway, I think it's worth the effort to do this.  It brings us a lot more
flexibility, because each view can provide its own set of plugins or
extensions for a single program.

Cheers

-- 
Julio M. Merino Vidal <jmmv@menta.net>
The NetBSD Project - http://www.NetBSD.org/