Add subdirectory support for DATA/DOCS with PGXS

Hi all,

Since moving PostGIS over to PGXS for the 1.4 release, we've been
looking at how we can support multiple versions of PostGIS being
installed in different databases within the same cluster.

We are able to version the .so file produced by PGXS without too much
difficulty, however PGXS in its current form does not have the ability
to install different versions of the DATA or DOCS files within the same
installation.

The attached patch is a prototype which allows the user to specify a new
MODULEDIR variable in a module makefile which, if specified, will
install DATA and DOCS items in contrib/$(MODULEDIR) rather than just
contrib. If MODULEDIR is left unspecified, the files will simply be
stored directly in contrib/ as before.

In my current development setup here, the head of the new PostGIS PGXS
Makefile now looks like this:

MODULE_big=postgis-1.5
MODULEDIR=$(MODULE_big)
...
...

With this patch in place, "make install" on the PGXS will correctly
install the DATA and DOCS files in versioned directories and therefore
allow multiple installations within the same database cluster.

The coding within the Makefile isn't too difficult in its current form,
but I'd be interested to get some initial feedback as to whether the
introduction of a new MODULEDIR variable is the best way to add this new
piece of functionality.

Many thanks,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

Mark Cave-Ayland wrote:

> The attached patch is a prototype which allows the user to specify a
> new MODULEDIR variable in a module makefile which, if specified,
> will install DATA and DOCS items in contrib/$(MODULEDIR) rather than
> just contrib. If MODULEDIR is left unspecified, the files will
> simply be stored directly in contrib/ as before.

As a proof of its usefulness, you could remove DATA_TSEARCH and replace
it with usage of MODULEDIR, right?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:

>> The attached patch is a prototype which allows the user to specify a
>> new MODULEDIR variable in a module makefile which, if specified,
>> will install DATA and DOCS items in contrib/$(MODULEDIR) rather than
>> just contrib. If MODULEDIR is left unspecified, the files will
>> simply be stored directly in contrib/ as before.
>
> As a proof of its usefulness, you could remove DATA_TSEARCH and replace
> it with usage of MODULEDIR, right?

Not in its current form because PGXS always places files underneath a
contrib/ subdirectory within datadir. However, if people are happier
with this approach then it shouldn't be too hard to alter things so that
my PGXS Makefile would look like this:

MODULE_big=postgis-1.5
MODULEDIR=contrib/$(MODULE_big)

Once in this form it should then be possible to use this code to replace
the DATA_TSEARCH variable that is currently in place.

ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

Mark Cave-Ayland <mark(dot)cave-ayland(at)siriusit(dot)co(dot)uk> writes:
> Alvaro Herrera wrote:
>> As a proof of its usefulness, you could remove DATA_TSEARCH and replace
>> it with usage of MODULEDIR, right?

> Not in its current form because PGXS always places files underneath a
> contrib/ subdirectory within datadir. However, if people are happier
> with this approach then it shouldn't be too hard to alter things so that
> my PGXS Makefile would look like this:
> MODULE_big=postgis-1.5
> MODULEDIR=contrib/$(MODULE_big)

If you can set it up in such a way that the default behavior doesn't
change, this would be workable. I don't think we want people to
suddenly find their stuff installing in the wrong place.

It probably wouldn't be that hard, something along the lines of
ifndef MODULEDIR
MODULEDIR=contrib
endif
ought to do it no?

regards, tom lane

Tom Lane wrote:

> If you can set it up in such a way that the default behavior doesn't
> change, this would be workable. I don't think we want people to
> suddenly find their stuff installing in the wrong place.
>
> It probably wouldn't be that hard, something along the lines of
> ifndef MODULEDIR
> MODULEDIR=contrib
> endif
> ought to do it no?

Yeah, that was pretty much along the lines of what I was thinking.
Please find the revised v2 patch attached for comment. The one thing I
have done is separated out the moduledir variable into datamoduledir and
docmoduledir so there is a little bit of wiggle room if someone needs to
install DATA items and DOCS items in different locations.

I did have a brief look at seeing whether it would be possible to use
this instead of DATA_TSEARCH, however this won't work because the DATA
and DATA_TSEARCH targets need their files installed in two separate
locations.

ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

Mark Cave-Ayland <mark(dot)cave-ayland(at)siriusit(dot)co(dot)uk> writes:
> Please find the revised v2 patch attached for comment. The one thing I
> have done is separated out the moduledir variable into datamoduledir and
> docmoduledir so there is a little bit of wiggle room if someone needs to
> install DATA items and DOCS items in different locations.

Why do DOCS still go into doc/contrib? Shouldn't that become
doc/$MODULEDIR for consistency?

regards, tom lane

Tom Lane wrote:

> Why do DOCS still go into doc/contrib? Shouldn't that become
> doc/$MODULEDIR for consistency?

Hmmm it looks as if the code was correct but I missed the comment at the
top of the file. Sorry for the confusion - revised version attached.

ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

Mark Cave-Ayland <mark(dot)cave-ayland(at)siriusit(dot)co(dot)uk> writes:
> Hmmm it looks as if the code was correct but I missed the comment at the
> top of the file. Sorry for the confusion - revised version attached.

Applied with minor fixups (mostly improving the documentation, which
was not in very good shape beforehand...)

regards, tom lane