With the assumption that the above "that one" refered to the "PG_CONFIG"
macro definition in "Makefile.global". As existing extension makefiles do
not defined PG_CONFIG, relying on one would break them wrt future
releases?
Ah, I see. I was thinking in terms of breaking them intentionally ;-)
Well, if that is what you want, is was perfect:-)
But ISTM that the remedy (breaking all past makefiles for all extensions)
is not worth the issue.
A better documentation, and possibly following your suggestion with an
explicit PG_CONFIG in contrib makefiles, but without breaking existing
extensions seems quite enough. The error made by Eddie is legitimate, but
it is also something rare, it did not come up in the last two years.
Please find attached a small patch which enhances the documentation on the
issue in my broken English.
If we're worrying about cross-version compatibility then it seems there
isn't any really nice way to make both combinations do the ideal thing.
If someone has an updated module Makefile, ie,
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
then it will look like changing PG_CONFIG in the Makefile would work;
but that will not work with an older PG release, because Makefile.global
will override the value.
Okay, there are indeed two different compatibility issues :
- "old" makefiles with possibly "new" pgxs conventions
- possibly "new" makefiles with "old" pgxs conventions
Indeed for "old" Makefile.global the PG_CONFIG is overwritten.
It would be okay if it is made clear that the PG_CONFIG macro MUST not be
updated from within the Makefile, but just from the commande line ?
Well that's still a little bit error prone anyway.
ISTM that the documentation update would suffice.
--
Fabien.
cd pgsql && ../pgsql/src/tools/make_diff/difforig
*** ./doc/src/sgml/xfunc.sgml.orig Thu Jun 7 01:00:36 2007
--- ./doc/src/sgml/xfunc.sgml Tue Jun 26 12:57:15 2007
***************
*** 2074,2081 ****
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
</programlisting>
! The last two lines should always be the same. Earlier in the
! file, you assign variables or add custom
<application>make</application> rules.
</para>
--- 2074,2091 ----
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
</programlisting>
! The last two lines must always be the same.
! The first <literal>pg_config</literal> found in the path is
! used to compile and install the extension.
! Changing the <literal>pg_config</literal> path manually in the
! <literal>Makefile</literal> will not work as it is used also elsewhere.
! The <term><varname>PATH</varname></term> must be redefined manually.
! The following syntax works with both sh and csh-compatible shells:
! <programlisting>
! shell$ make PATH=/path/to/another/postgresql/bin:$PATH all
! shell$ make PATH=/path/to/another/postgresql/bin:$PATH install
! </programlisting>
! Earlier in the file, you assign variables or add custom
<application>make</application> rules.
</para>
*** ./src/makefiles/pgxs.mk.orig Tue Jun 26 12:49:00 2007
--- ./src/makefiles/pgxs.mk Tue Jun 26 12:56:47 2007
***************
*** 14,19 ****
--- 14,27 ----
# PGXS := $(shell pg_config --pgxs)
# include $(PGXS)
#
+ # You cannot use a full path for the above pg_config command. The chosen
+ # postgresql must be the first one found in the PATH. The PATH must be updated
+ # for compiling an extension against another postgresql installation.
+ # This can be achieved with the following syntax:
+ #
+ # shell> make PATH=/path/to/another/postgresql/bin:$PATH all
+ # shell> make PATH=/path/to/another/postgresql/bin:$PATH install
+ #
# The following variables can be set:
#
# MODULES -- list of shared objects to be build from source file with
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
