Fabien COELHO <[EMAIL PROTECTED]> writes: > 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 ;-) but perhaps that's not such a great idea. The reason that I was thinking that way was that as long as module Makefiles look like PGXS := $(shell pg_config --pgxs) include $(PGXS) there will be room for people to make the same mistake as Eddie, ie, try to modify that shell command to select a pg_config that's not first in $PATH. 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. So neither way of writing the module Makefile is going to be foolproof with both old and new PG installations. Reading between the lines in the gmake manual, it seems like writing the module Makefile as override PG_CONFIG := pg_config etc might work to override the setting in old copies of Makefile.global, but this cure is worse than the disease, because it prevents specifying PG_CONFIG on the make command line. (And I'm not sure it works anyway; have not tried it.) Anyone see a way to handle all these cases at the same time? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org