[PATCH] Support built control file in PGXS VPATH builds - Mailing list pgsql-hackers

From Craig Ringer
Subject [PATCH] Support built control file in PGXS VPATH builds
Date
Msg-id CAMsr+YE6sG=KgpSAFEhTbrNq48M4_U0_2V+d2Vp3Hn75gfZLkQ@mail.gmail.com
Whole thread Raw
Responses Re: [PATCH] Support built control file in PGXS VPATH builds
List 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

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: typos in comments and user docs
Next
From: Kasahara Tatsuhito
Date:
Subject: Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)