Fabien COELHO <coelho@cri.ensmp.fr> 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
