Thread: pgxs: build infrastructure for extensions v4
Dear patchers,
Please find attached another new version of a patch which provides a
working infrastructure for pg extensions. I hope it addresses all of
Peter's comments. I'll be away for the next 3 weeks, so if minor changes
are required it would be best if you could proceed without me...
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. The documentation is added as a new section in
"xfunc.sgml".
I updated all contrib makefiles so that they can be used either the
standard way after a configure, or the new way without needing a configure
but with an already installed postgreSQL. Just try them with
"cd contrib/foo ; make USE_PGXS=1 install"
*AFTER* postgresql has been configure, compiled and installed. It should
be compiled and installed wrt to the first "pg_config" which is found in
the path.
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.
- I've added two PGXS-triggered conditionnals in Makefile.global,
so that includes and libraries are taken where needed.
Notes:
- there is still a "light-install" target that matches the previous
"install" behavior, as new "install" matches previous "server-install".
- I'm not sure the sgml is ok. It looks ok, but is it enough.
- It validates and works for me.
Have a nice day,
--
Fabien Coelho - coelho@cri.ensmp.fr
Attachment
I have Peter reviewing this. --------------------------------------------------------------------------- Fabien COELHO wrote: > > Dear patchers, > > > Please find attached another new version of a patch which provides a > working infrastructure for pg extensions. I hope it addresses all of > Peter's comments. I'll be away for the next 3 weeks, so if minor changes > are required it would be best if you could proceed without me... > > 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. The documentation is added as a new section in > "xfunc.sgml". > > I updated all contrib makefiles so that they can be used either the > standard way after a configure, or the new way without needing a configure > but with an already installed postgreSQL. Just try them with > > "cd contrib/foo ; make USE_PGXS=1 install" > > *AFTER* postgresql has been configure, compiled and installed. It should > be compiled and installed wrt to the first "pg_config" which is found in > the path. > > > 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. > > - I've added two PGXS-triggered conditionnals in Makefile.global, > so that includes and libraries are taken where needed. > > > Notes: > > - there is still a "light-install" target that matches the previous > "install" behavior, as new "install" matches previous "server-install". > > - I'm not sure the sgml is ok. It looks ok, but is it enough. > > - It validates and works for me. > > > Have a nice day, > > -- > Fabien Coelho - coelho@cri.ensmp.fr Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Fabien COELHO wrote: > Please find attached another new version of a patch which provides a > working infrastructure for pg extensions. I hope it addresses all of > Peter's comments. I'll be away for the next 3 weeks, so if minor > changes are required it would be best if you could proceed without > me... This patch breaks building outside the source tree in a very elaborate and obvious way. Unfortunately, this is all tied together so I haven't figured out yet if it can be fixed easily. Also, the use of the install targets is a bit strange (install-all-headers install libpgport.a). I would simply not bother and install everything all the time. However, those who advocate the install-all-headers target may want to propose a different scheme. > I updated all contrib makefiles so that they can be used either the > standard way after a configure, or the new way without needing a > configure but with an already installed postgreSQL. Just try them > with > > "cd contrib/foo ; make USE_PGXS=1 install" > > *AFTER* postgresql has been configure, compiled and installed. It > should be compiled and installed wrt to the first "pg_config" which > is found in the path. This is redundant. I think by now I'm looking for a patch that does not touch contrib at all (except perhaps contrib-global.mk). Much of the trouble arises from being too clever around there. We're trying to allow external modules to build, not internal ones. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
> Fabien COELHO wrote:
>> Please find attached another new version of a patch which provides a
>> working infrastructure for pg extensions.
> This patch breaks building outside the source tree in a very elaborate
> and obvious way. Unfortunately, this is all tied together so I haven't
> figured out yet if it can be fixed easily.
Peter, do you have time before the end of the month to sort this out?
It would be nice to have a real solution in this area, because certainly
we have some problems here.
> I think by now I'm looking for a patch that does not
> touch contrib at all (except perhaps contrib-global.mk).
I would think that we'd want to make the contrib tree use whatever
solution is developed for building outside the main source tree, simply
because that's a handy test case for verifying that it's not broken.
I won't commit hara-kiri if this is not solved for 7.5, but it is an
open issue, especially for RPM and similar package installations.
If Fabien's work is at all close to a usable solution, it'd be a shame
not to get it done in this release cycle.
regards, tom lane
Tom Lane wrote: > Peter, do you have time before the end of the month to sort this out? > It would be nice to have a real solution in this area, because > certainly we have some problems here. Yes, I'll make sure it gets done. By the way, extra credit for someone who manages to get slony1 to build using this framework. I'm not sure it's possible, though. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Dear peter, > > Please find attached another new version of a patch which provides a > > working infrastructure for pg extensions. I hope it addresses all of > > Peter's comments. I'll be away for the next 3 weeks, so if minor > > changes are required it would be best if you could proceed without > > me... > > This patch breaks building outside the source tree in a very elaborate > and obvious way. Unfortunately, this is all tied together so I haven't > figured out yet if it can be fixed easily. I do not get your point. the aim is to be able to build outside the source tree as well? > Also, the use of the install targets is a bit strange > (install-all-headers install libpgport.a). I would simply not bother > and install everything all the time. However, those who advocate the > install-all-headers target may want to propose a different scheme. part of this existed before the patch. I tried to make the best of existing targets, especially as you requested that less targets should be used. I do agree with you that installing libgport.a under install-all-headers looks stupid, but the idea behind all-headers is that all which is required for extensions is installed. What about install-dev-files? or anything less misleading? > > I updated all contrib makefiles so that they can be used either the > > standard way after a configure, or the new way without needing a > > configure but with an already installed postgreSQL. Just try them > > with > > > > "cd contrib/foo ; make USE_PGXS=1 install" > > > > *AFTER* postgresql has been configure, compiled and installed. It > > should be compiled and installed wrt to the first "pg_config" which > > is found in the path. > > This is redundant. I think by now I'm looking for a patch that does not > touch contrib at all (except perhaps contrib-global.mk). I really just touch that file in contrib. The only other exceptions are when other files were directly included or to reorder include wrt mqcro definitions, as far as I can remember. > Much of the trouble arises from being too clever around there. We're > trying to allow external modules to build, not internal ones. I really want to be able to install contribs as an afterthought and without reconfiguring. anyway, sorry I cannot really help as I m away from home. Have a nice day, -- Fabien Coelho - coelho@cri.ensmp.fr
Am Freitag, 16. Juli 2004 16:34 schrieb Fabien COELHO: > Please find attached another new version of a patch which provides a > working infrastructure for pg extensions. I hope it addresses all of > Peter's comments. I'll be away for the next 3 weeks, so if minor changes > are required it would be best if you could proceed without me... Done. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Applied by Peter. --------------------------------------------------------------------------- Fabien COELHO wrote: > > Dear patchers, > > > Please find attached another new version of a patch which provides a > working infrastructure for pg extensions. I hope it addresses all of > Peter's comments. I'll be away for the next 3 weeks, so if minor changes > are required it would be best if you could proceed without me... > > 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. The documentation is added as a new section in > "xfunc.sgml". > > I updated all contrib makefiles so that they can be used either the > standard way after a configure, or the new way without needing a configure > but with an already installed postgreSQL. Just try them with > > "cd contrib/foo ; make USE_PGXS=1 install" > > *AFTER* postgresql has been configure, compiled and installed. It should > be compiled and installed wrt to the first "pg_config" which is found in > the path. > > > 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. > > - I've added two PGXS-triggered conditionnals in Makefile.global, > so that includes and libraries are taken where needed. > > > Notes: > > - there is still a "light-install" target that matches the previous > "install" behavior, as new "install" matches previous "server-install". > > - I'm not sure the sgml is ok. It looks ok, but is it enough. > > - It validates and works for me. > > > Have a nice day, > > -- > Fabien Coelho - coelho@cri.ensmp.fr Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073