pgxs: build infrastructure for extensions v2

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: pgxs: build infrastructure for extensions v2
Date: 2004-06-25 14:19:32
Message-ID: Pine.LNX.4.58.0406251601360.31478@sablons.cri.ensmp.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


Dear patchers,

Please find attached a new version of a patch which provides a working
infrastructure for pg extensions. It addresses most of Peter comments.
I wish it could make it for version 7.5.

The infrastructure is a simple reworking of the already available internal
infrastructure for contrib, so that it can be used outside of the postgresql
source tree after installation, without gory details being in sight of
the user. There is an initial documentation in "pgxs.sgml".

As a test case and show how, I provided new "pgxs.mk" makefiles for most
contrib subdirectories. Just try them with

"cd contrib/foo ; make -f pgxs.mk install"

*AFTER* postgresql has been configured, compiled and installed.

How it works:

- necessary files (includes, scripts, makefiles...) are copied under
$(pkglibdir)/pgxs on the initial "make install".

due to gnu-make restriction on how its includes work, these files must
be copied with the *same* directory structure as the pg source tree.
The fact does not appear at all in the actual infrastructure from the
user point of view, but it explains why subdirectories are necessary
under pgxs, if you care to have a look.

- the makefile of any extension is expected to set macro PGXS to
"pg_config --pgxs", to include a special makefile, and to
set some macros depending on what is to be built, just like in
current contrib. See the examples under contrib.

- I've added two PGXS-triggered conditionnals in Makefile.global,
so that includes and libraries are taken where needed.

About Peter comments:

> - Regarding GNUmakefile.in changes: files in directory foo/ must be
> handled by a makefile in directory foo/, so these changes must be moved
> to a makefile in config/.

Ok. done.

> - Please don't invent new targets like light-install, install-local.
> Just install everything in the install target.

I removed *-local targets, at the price of less factorization but better
maybe clarity.n

However "light-install" is a packager-friendly version to install only
what is required for running postgresql, while install includes what is
needed for compiling extensions. I fill the former is also useful. It is
also what "install" did before the patch.

> - The uninstall target may only remove what it installed, not "*".

Ok. done.

> - Don't invent new installation directories; there are enough already.
> Platform dependent data files (which these are) go into/under
> $(pkglibdir).

Ok. It is now in $(pkglibdir)/pgxs, and I dropped the configure option.
It looks both simpler and better now.

> - Referring to the renaming of all makefiles under contrib/: I'm not in
> favor of naming makefiles Makefile.foo; it should be foo.mk. This
> makes it easier for tools that recognize files by extension.

Ok. Now these example makefiles are named "pgxs.mk".

> PGXS := $(shell pg_config --pgxs)
> include $(PGXS)/pgxs.mk
> but why not
> PGXS := $(shell pg_config --pgxs)
> include $(PGXS)

Ok. done.

I use the PGXS macro to recompute top_builddir, and it was a little bit
simpler if it was already a directory.

> - Incidentally, the above will fail if pg_config is not installed (yet),

Yes.

> so it can't be used in the contrib/ directories.
> (The contrib directories are at least cleaned by the top-level makefile,
> this this is a must-fix failure.)

Well, I think it can be used anyway:

If you cannot compile extensions before postgresql is already installed,
then there would be nothing to clean;-) Once it is installed, then you can
make clean with pgxs and it should work. So it is consistent.

The issue I see is more political: does the pgxs stuff is promoted as
"the way to add contribs or whatever to postgresql", and the old
contrib makefiles are just replaced, -- or they are kept, so that one
can compile contrib without postgresql being already installed, the
old way.

In the former case, then sure the "make clean" should be fixed not
to propagate under contrib. The current situation from this patch is
that I did not removed the old stuff, so the pgxs.mk makefiles are
just examples and can be used to install contribs as an afterthought.

> - In Makefile.global: -L$(pkglibdir) is not necessary. There are not
> libraries to link at build time in there.

It is done only "ifdef PGXS", in which case it seems to me that
this is really needed, as it is at extension-building time.

> - -I$(includedir) and -L$(libdir) cannot be used. In an average
> installation that resolves to -I/usr/include and -L/usr/lib, which
> breaks GCC and other compilers.

Ok. done.

Still maybe open issues, or thought for the future:

- maybe more files should be copied? if so which ones?

- should this actually replace the current "contrib" infrastructure?

I would tend to say "yes"... that would require to replace all makefiles
there by the pgxs.mk version, to remove "contrib-global.mk", and to
also possibly to update some documentation.

However as a consequence, contribs would need to be compiled and
installed only *after* postgres is installed, although at the time
they can be compiled once postgresql is configured.

See the discussion above in my response to Peter comments.

- More documentation? Integration of the documentation wrt pg doc?

- validation? one could thing of installing some contribs
when "make check" is performed, so as to validate that the
extension infrastructure is not broken?

Have a nice day,

--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr

Attachment Content-Type Size
install_build.patch text/plain 39.5 KB

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-06-25 15:10:17 Re: Compile failure with SSL
Previous Message Christopher Kings-Lynne 2004-06-25 06:39:09 add missing options to pg_dumpall