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

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.

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)
!     The last two lines should always be the same.  Earlier in the
!     file, you assign variables or add custom
      <application>make</application> rules.
--- 2074,2091 ----
  PGXS := $(shell pg_config --pgxs)
  include $(PGXS)
!     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.
*** ./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

Reply via email to