On Sun, 22 Aug 2004, Czuczy Gergely wrote:

> On Sun, Aug 22, 2004 at 11:39:38AM -0700, Stephan Szabo wrote:
> >
> > On Sun, 22 Aug 2004, Czuczy Gergely wrote:
> >
> > > I've attached a corrected patch, the postgresql.pc.in was missing.
> > >
> > > On Sun, Aug 22, 2004 at 01:49:08PM -0400, Tom Lane wrote:
> > > > [EMAIL PROTECTED] (Czuczy Gergely) writes:
> > > > > I've added a pkg-config script.
> > > > > The "diff -rc -x configure from to" output is attached.
> > > >
> > > > Considering that this patch is lacking both the script itself, and any
> > > > documentation, it's not got much hope of being accepted...
> > > What kind of documentation does it need? i don't see.
> >
> > Well, you've added a configure option, so the installation sgml at the
> > very least.  If it's meant to replace or do the same general thing as
> > pg_config, then the places pg_config is mentioned in mainline docs should
> > probably be added to as well (libpq and xfunc).
> not replaces, just an alternative.

Well, it probably should get a mention in those places.  In addition, the
dangers of the below need to be mentioned somewhere.

> > > > But before you run off to produce those things, I would suggest
> > > > putting up a proposal on pghackers about what you want to do
> > > > and why.  In particular, what problem are you solving that isn't
> > > The most common way to get a package's libflags and cflags is the solution
> > > that pkg-config offers. the problem with pg_config that it's not in the path,
> > > it's place depends on the prefix, so to use it required an extra effort.
> > > pkg-config is a standardized way to check for a package's libs and cflags.
> > > The patch I've made adds the generation of this script, and extends the Makefiles
> > > to install them. The place of this .pc (Pkg-Config) file is at 
> > > /usr/lib/pkgconfig/,
> > > but with the patch it can be altered with --with-pkgconfig-dir.
> >
> > How is the pkg-config stuff meant to interact with having multiple
> > different installations on a machine? I might, for example, have two or
> > three copies of the same version of postgresql with different options
> > under some circumstances.
> it doesn't. pkg-config is a very simple thing, good for generalism. what
> you are talking about is an extrem environment, as I noticed, less then
> 1% of the users have this. on the other side the vast majority's configure, pmk,
> and so on scripts do not find the required config script, because it's out-of-path,
> and has to be given by hand. for these situation pkg-config provides a simple
> solution, adds a general file to the place, and whenever a configure/pmk/etc script
> needs the libs/cflags/so on it can ask pkg-config for it. no need to search for
> pg_config's location. anyway, if you want to have multiple installations, it can be
> solved but that will break the generalism that pkg-config provides. adding some
> kind of suffix to the .pc file, like postgresql-myinstance.pc, or so. But, as I've
> said it will break the generalism, because the configure/pmk/etc scripts look for
> 'postgresql', not 'postgresql-myinstance'.

Can the users do that without manually modifying the file with the patch
you've provided?  It seems like there'd be a non-zero chance of those
outside packages using pkg-config actively getting incorrect results for
people with multiple installations. And, those outside packages would have
no way to get the "right" information unless they allow you to change the
name to look for, which makes them effectively broken for those users.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to