> Am Dienstag, 10. August 2004 17:55 schrieb Fabien COELHO:
> > (1) all makefiles in contrib include directly "src/Makefile.global" which
> > is generated by configure, although it is already included by the
> > "src/makefiles/pgxs.mk" makefile anyway, so it seems to me that it
> > is useless because redundant?
> No, because you need Makefile.global to define top_srcdir, which is needed to
> find pgxs.mk.
> You changed all top_srcdir to top_builddir, which is wrong.
I agree it may be wrong, although it worked in my simple tests.
Maybe you could explain why it is wrong?
What is the actual issue with these two macros?
I guess I miss something about the "vpath" feature?
There is a chicken and egg issue here for a simple makefile macro, the
implications are unclear to me, and I'm willing to find a fix.
It looks to me that when using the dynamic feature of pgxs, then the
abs_top_srcdir does not make sense as one cannot know whether the sources
would be extracted in the same directory. This suggest that maybe some
carefull ifdef could fix the stuff? I can suggest the following in every
# Fabien's way
PGXS = $(shell pg_config --pgxs)
# Peter's way
# Now top_srcdir is defined:
Would you find it better?
> > (2) only static includes are used, so I cannot use "pg_config --pgxs"
> > approach to install a contrib against an already compiled postgresql?
> > basically, you drop the USE_PGXS stuff for dynamic configuration
> > of contrib makefiles, and I have found no replacement.
> I don't see the point of that.
> If you have a PostgreSQL source tree, you can install the contribs right
My objective in pgxs wrt contrib is to be able to add a contrib as an
afterthought: say, I installed a postgresql server 10 months ago and now I
would like to test tsearch2 with that server. I don't want to reconfigure
the whole thing, I just have a few files to compile.
With apache, I can do a "apxs -someoptions mod_somemodule.c" to install
any "simple" module, and that is the kind of feature I'm looking for.
If pgxs can be used to add external modules, there is no reason why we
could not use it to also install a contrib, the issue is just about the
makefile and how to handle it.
In my first submissions I provided a separate makefile which is basically
a copy of the original makefile with one line fixed. You argued that they
that it added a maintenance burden. So as they are very similar, in a
later submission I merged the two files, but then you removed the key
feature I was adding:-(
> How else would you do it?
With the "dynamic configuration" provided pgxs, not relying on the files
in the source tree but relying on the ones installed. That why I copy all
those files... adding any extension, external or in contrib, does not
need to rely on the configured source tree.
Have a nice day,
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2004-08-12 09:06:59|
|Subject: Re: pg_restore (libpq? parser?) bug in 8|
|Previous:||From: Hans-Jürgen Schönig||Date: 2004-08-12 06:52:53|
|Subject: Re: Regression failure with PostgreSQL 8beta1 and Intel|
pgsql-committers by date
|Next:||From: Bruce Momjian||Date: 2004-08-12 14:58:37|
|Subject: pgsql-server: Minor style cleanup of thread test script.|
|Previous:||From: Tom Lane||Date: 2004-08-11 23:28:56|
|Subject: pgsql-server: Cause initdb to actually accept -s as intended, and fix |