Dear Eddie,
> MODULES = example
> PGXS := $(shell ~/install_dir/bin/pg_config --pgxs)
This is indeed not the intented use of pgxs: it breaks a desirable
property of the makefile that is should be "generic" wrt postgresql, that
is not particular to an installation.
You are really expected to rely on the path, although the definition you
wrote is indeed tempting, although doomed to failure. From the
documentation, one finds:
"""
33.9.7. Extension Building Infrastructure
...
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
The last two lines should always be the same. Earlier in the file, you
assign variables or add custom make rules.
...
The extension is compiled and installed for the PostgreSQL installation
that corresponds to the first pg_config command found in your path.
"""
There could be a clearer comment about the path assumption in "pgxs.mk"
and how to change the path easily from the shell? The "should be the
same" could be changed for "MUST always be the same..." with some
additional comments.
> Could this have been avoided if the Makefile.global had
> PG_CONFIG = $(prefix)/bin/pg_config ?
That would not work, because "pg_config" is needed to know what the prefix
(or rather bindir) is, as Tom pointed out. I think this is also because
the "installation" may be moved around, so it is not necessarily the
configure-time prefix which is used with some package systems.
His suggestion about using a PG_CONFIG macro in the initial makefile,
which may be redefined if required, would also provide an alternative way
supplying the right pg_config, at the price of one additional line. Mm.
I think a doc improvement is at least welcome.
--
Fabien.
