Mark Cave-Ayland 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...)
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 - Sen
Mark Cave-Ayland 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 differen
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
Mark Cave-Ayland 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
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 b
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
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
