Re: gtk-all tarball, pkg-config changes to allow giant tarballs
- From: James Henstridge <james daa com au>
- To: Havoc Pennington <hp redhat com>
- Cc: Raja R Harinath <harinath cs umn edu>, <gtk-devel-list gnome org>, <gnome-hackers gnome org>
- Subject: Re: gtk-all tarball, pkg-config changes to allow giant tarballs
- Date: Fri, 18 May 2001 17:50:08 +0800 (WST)
On 17 May 2001, Havoc Pennington wrote:
>
> Raja R Harinath <harinath cs umn edu> writes:
> > > First, pkg-config will prefer the file foo-uninstalled.pc rather than
> > > foo.pc if you request the module 'foo'.
> >
> > This shouldn't be the default behaviour. It is not inconcievable that
> > 'foo-uninstalled.pc' does get mistakenly installed somewhere. Such
> > mistakes should not be compounded by such defaults. There should be a
> > command line switch for this.
>
> The problem with this is that there are several dozen calls to
> pkg-config, and you need to add the switch to all of them.
>
> If we don't want it to be the default, one way is a
> PKG_CONFIG_ENABLE_UNINSTALLED env variable to be exported at the top
> of configure.in. But I really don't think installing
> foo-uninstalled.pc will happen much - I mean, the file is called
> "uninstalled" - adding it to an inst target would be pretty
> boneheaded, quickly caught, and easy to fix. I just don't see much
> problem there.
Do you even need to worry about the -uninstalled.pc variants? Would it be
enough to have dummy versions of glib-2.0.pc, etc in the base of this big
package, and set PKG_CONFIG_PATH so that these will be found before
possibly installed versions of the files? (Setting PKG_CONFIG_PATH could
be done in the toplevel configure script before the module configure
scripts are called). Wouldn't this be easier than hacking pkg-config?
James.
--
Email: james daa com au
WWW: http://www.daa.com.au/~james/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]