pgxs.mk assumes that if $(EXTENSION) is set, a file $(EXTENSION).control must exist in the $(srcdir).
Extensions that need to support multiple Pg versions, multiple variants of the extension, etc may need to template their extension control file. PGXS's assumption prevents those extensions from supporting read-only source trees for true vpath builds. A workaround is to ignore the EXTENSION field in PGXS and leave it unset, then set MODULEDIR to the value you would've set EXTENSION to and install your control file with DATA_built . But that's more than a tad ugly. The attached patch fixes this by having PGXS resolve $(EXTENSION).control along the VPATH. Before: /usr/bin/install: cannot stat '/the/srcdir/path/the_extension.control': No such file or directory make: *** [/the/postgres/path/lib/postgresql/pgxs/src/makefiles/pgxs.mk:229: install] Error 1 After: no error, extension control file is found in builddir. There's no reference to $(EXTENSION) outside pgxs.mk so this shouldn't have any wider consequences. The extension is responsible for the build rule for the control file, like in DATA_built etc. Please backpatch this build fix. I could supply an alternative patch that follows PGXS's existing convention of using a _built suffix, allowing the extension to specify either EXTENSION or EXTENSION_built. For backward compat we'd have to allow both to be set so long as they have the same value. Personally I dislike this pattern and prefer to just resolve it in normal Make fashion without caring if it's a built file or not, especially for the EXTENSION var, so I'd prefer the first variant. Frankly I'd rather we got rid of all the $(VAR) and $(VAR_built) stuff entirely and just let make do proper vpath resolution. But I'm sure it's that way for a reason... I have a few other cleanup/fixup patches in the pipe for PGXS and Makefile.global but I have to tidy them up a bit first. One to eliminate undefined variables use, another to allow vpath directives to be used instead of the big VPATH variable hammer. Keep an eye out. -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise
From b187e31cb4e27892b8ca71e5e3feb3de389ee1e1 Mon Sep 17 00:00:00 2001 From: Craig Ringer <cr...@2ndquadrant.com> Date: Fri, 7 Feb 2020 11:05:24 +0800 Subject: [PATCH] PGXS support for built control files Teach PGXS how to find the extension control file via the vpath, rather than assuming that it's always in the $(srcdir). This allows extensions with more complex needs to template their extension files without breaking vpath support. Extensions can work around this issue on older PostgreSQL releases by: * Setting MODULE_DIR instead of EXTENSION * Adding their extension control file to DATA_built --- src/makefiles/pgxs.mk | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/src/makefiles/pgxs.mk b/src/makefiles/pgxs.mk index 037307c076..dcd3b3e48c 100644 --- a/src/makefiles/pgxs.mk +++ b/src/makefiles/pgxs.mk @@ -207,7 +207,6 @@ endef # end of HEADERS_* stuff - all: $(PROGRAM) $(DATA_built) $(HEADER_allbuilt) $(SCRIPTS_built) $(addsuffix $(DLSUFFIX), $(MODULES)) $(addsuffix .control, $(EXTENSION)) ifeq ($(with_llvm), yes) @@ -223,11 +222,18 @@ include $(top_srcdir)/src/Makefile.shlib all: all-lib endif # MODULE_big - -install: all installdirs +# Resolve the extension control file along the VPATH, so we can find both built +# and static file control files. +# ifneq (,$(EXTENSION)) - $(INSTALL_DATA) $(addprefix $(srcdir)/, $(addsuffix .control, $(EXTENSION))) '$(DESTDIR)$(datadir)/extension/' -endif # EXTENSION +install_controlfile: $(addsuffix .control, $(EXTENSION)) | installdirs + $(INSTALL_DATA) $< '$(DESTDIR)$(datadir)/extension/' +else +install_controlfile: ; +endif + + +install: all installdirs install_controlfile ifneq (,$(DATA)$(DATA_built)) $(INSTALL_DATA) $(addprefix $(srcdir)/, $(DATA)) $(DATA_built) '$(DESTDIR)$(datadir)/$(datamoduledir)/' endif # DATA -- 2.24.1
