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.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to