pgxs: build infrastructure for extensions v2 - Mailing list pgsql-patches
From | Fabien COELHO |
---|---|
Subject | pgxs: build infrastructure for extensions v2 |
Date | |
Msg-id | Pine.LNX.4.58.0406251601360.31478@sablons.cri.ensmp.fr Whole thread Raw |
Responses |
Re: pgxs: build infrastructure for extensions v2
|
List | 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@cri.ensmp.fr
Attachment
pgsql-patches by date: