Re: Tom Lane 2016-04-15 <6344.1460728679@sss.pgh.pa.us>
> Could we insist that for a cross-compilation, the appropriate instance
> of pg_config has to be found first in the PATH under the name pg_config?
> That turns it into a matter of preparing the build environment.
The "compile twice" idea sounds very fragile, and I'm not sure if
compiling things for the local machine is even feasible in a
cross-compilation environment without relying on non-standard things.
Couldn't we simply (?) have two implementations? Keep the current C
implementation for Windows, and supply a sh implementation for all
other systems? Of course maintaining two implementations of the same
thing causes a maintenance burden, but pg_config is small.
> A different line of thought is to expose the data as data rather than
> an executable. For example, as a makefile fragment containing variable
> assignments, which would be include'd by extension makefiles. There
> are a lot of problems to be solved with this idea too, of course:
> what do you do to make it play in non-make-based build systems? And
> where would this file live? The lack of a PATH mechanism makes it
> far harder for would-be users to find the file. Still, maybe we could
> make something out of that approach.
As Peter said in the Debian bug I was citing, people should actually
be using pkg-config. I agree with that, but we don't even have
a .pc interface yet for retrieving server variables, and until that or
the pgxs-as-Makefile idea (which is nice too) are implemented,
pg_config will still be used for years in existing code out there.
Christoph