[PATCH] Support built control file in PGXS VPATH builds

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: [PATCH] Support built control file in PGXS VPATH builds
Date: 2020-02-07 03:14:57
Message-ID: CAMsr+YE6sG=KgpSAFEhTbrNq48M4_U0_2V+d2Vp3Hn75gfZLkQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
0001-PGXS-support-for-built-control-files.patch text/x-patch 1.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kasahara Tatsuhito 2020-02-07 03:27:26 Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)
Previous Message Justin Pryzby 2020-02-07 03:11:26 Re: typos in comments and user docs