Thread: build infrastructure for extensions v3
Dear patchers, Please find attached version number 3 for a patch to enable extensions such as contribs or external add-ons to be installed simply with an already installed postgresql. This version addresses Peter's comments about src/makefiles/Makefile.* that do not need to be installed. It works for me, as previous versions. See other comments in previous submissions and responses. -- Fabien.
Attachment
Wow, that is a big patch.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Fabien COELHO wrote:
>
> Dear patchers,
>
> Please find attached version number 3 for a patch to enable extensions
> such as contribs or external add-ons to be installed simply with an
> already installed postgresql.
>
> This version addresses Peter's comments about src/makefiles/Makefile.*
> that do not need to be installed. It works for me, as previous versions.
>
> See other comments in previous submissions and responses.
>
> --
> Fabien.
Content-Description:
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
--
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
Bruce Momjian wrote: > Wow, that is a big patch. > > Your patch has been added to the PostgreSQL unapplied patches list > at: > > http://momjian.postgresql.org/cgi-bin/pgpatches > > I will try to apply it within the next 48 hours. ISTM that this version still does not allow building contrib without having installed pg_config first. That is a no-no.
Peter Eisentraut <peter_e@gmx.net> writes:
> ISTM that this version still does not allow building contrib without
> having installed pg_config first. That is a no-no.
Sounds like the list of objections is getting shorter anyway ;-). Do
you feel that this patch is going in basically the right direction?
I've not had any time to look at it myself ...
regards, tom lane
Dear Peter,
> ISTM that this version still does not allow building contrib without
> having installed pg_config first.
This version DOES allow building contrib without having installed
pg_config first. Indeed, I did not remove the previous infrastructure;-)
I play a little bit on words, but it is a fact anyway. With the submitted
patch, you just need to type "make" to compile contrib as usual!
(1) The main aim of the infrastructure is not for contribs but for
external modules. There is not such issue for external add-ons.
I preliminarily provided the contrib makefiles as "how to" examples.
(2) What the patch adds is the ability to ALSO install a contrib as an
afterthought. It also enable external (non contrib) modules to rely on it
so they can be installed much more simply. You have to invoke
"make -f pgxs.mk" to do that, as the makefile is a little bit different.
So the issue would be relevant if the old makefiles were to be removed,
which is not the case with the submitted patch. If they were to be
removed, I also have an opinion at the time. I may be wrong, but this my
opinion nevertheless without further arguments:
(3) I think it is not a real issue. The argument you gave is "packagers
will need to compile contribs without installing postgresql first". My
point is that if they can do that with apache, they should survive with
postgresql just the same.
More specifically, I think that it is much better to be able to compile a
contrib or any external module without having to reconfigure the sources,
and even without needing to get them.
Now if you have other arguments, or that you can explain to me why this
fact is such an issue, I may change my point of view.
(4) I could fix the contrib pgxs makefiles so that they check for
something, like:
PG := $(shell type pg_config 2> /dev/null)
ifeq ($(PG),)
# postgresql is not installed...
else
# postgresql is installed...
endif
so what?
1. Even if there is pg_config in the path, that would not
necessarilly mean that the user want to compile with it.
2. This would make the contrib pgxs makefiles different from
what they are expected to be for external modules. I intended
these makefiles as examples, and now they would be different from
what is needed.
If you have a cool idea to make the original extension makefile to work in
any case without modification, I'm interested, because it would enable to
have both worlds and everybody would be happy!
(5) As a improvement to the submitted version, I could think of mixing the
current (contrib/contrib-global.mk) and (src/makefiles/pgxs.mk) files so
that the core of the extension makefile is not replicated. But that would
not change the issue we're discussing.
So I'm still reserved about your reserves. Moreover I think that this
patch adds something and does not remove anything, and that it is
desirable to have an "extension infrastructure" for external modules in
the upcoming version, whether it is this one or anything else.
Although not perfect, this one is much better than nothing.
Anyway, if having a unique infrastructure is a definite blocking
constraint, I can implement (4) above, even if I think it is not such a
good idea.
So you decide. As I'll away during 3 weeks from July 19, it would be
better to decide quickly so that I can make the necessary changes before
leaving.
Have a nice day,
--
Fabien Coelho - coelho@cri.ensmp.fr
Fabien COELHO wrote: > Dear patchers, > > Please find attached version number 3 for a patch to enable > extensions such as contribs or external add-ons to be installed > simply with an already installed postgresql. OK, I think we're getting somewhere. I am still opposed to adding more targets of the form "light-install", "client-only install", etc. Please discuss this on -hackers. It can be done as a separate patch later on if need be. While I now understand what you are doing in contrib, I ask who is going to want to maintain two parallel sets of makefiles, one for PGXS and one for in-tree builds? One who is going to want to use the PGXS ones anyway? I realize they're good examples, but examples should be put into the documentation, so people can find them. Paste your documentation (pgxs.sgml) somewhere into xfunc.sgml, where it discusses writing user-defined functions. This material isn't long enough to warrant a chapter of its own. + ifdef PGXS + LDFLAGS += -L$(pkglibdir) + endif needs to disappear. There is nothing to link with in there. (If there is, that's a bug.) libpgport should be installed in the normal libdir. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Dear Peter, > I am still opposed to adding more targets of the form "light-install", It is a renaming of the previous 'install' target, as the new install is the previous 'server-install', so it is no different from the current status. I let 'light-install' as a compromise wrt Tom view that the default installation should not include header files, so that it would be still easy to do that... > "client-only install", etc. Ok, as you wish. I just felt it was easy and useful. > Please discuss this on -hackers. It can be done as a separate patch > later on if need be. Ok. > While I now understand what you are doing in contrib, I ask who is going > to want to maintain two parallel sets of makefiles, one for PGXS and one > for in-tree builds? Yep, that is indeed a good point. > One who is going to want to use the PGXS ones anyway? Well, I've been disappointed in the past when I wanted to test a contrib and had to reconfigure everything to do so. So I really think it is useful to be able to add contribs as an after-thought. I really tend to think that there could be the pgxs only version, but that would break "compile without installing", and you don't want that, as previously discussed. So there is no perfect solution:-( What I can do is to enable the current makefiles to use pgxs if desired by the user, maybe with some switch, say "make install" vs "make USE_PGXS=yes install"... I'll lose the clean illustration part but would have one makefile only and still enable using pgxs if needed. > I realize they're good examples, but examples should be put into the > documentation, so people can find them. Humm. > Paste your documentation (pgxs.sgml) somewhere into xfunc.sgml, where it > discusses writing user-defined functions. This material isn't long > enough to warrant a chapter of its own. Ok. > + ifdef PGXS > + LDFLAGS += -L$(pkglibdir) > + endif > > needs to disappear. There is nothing to link with in there. (If there > is, that's a bug.) I think I added it because it did not work without that, but I can recheck whether it is really needed. > libpgport should be installed in the normal libdir. Ok. I'll submit a new patch on tomorrow to hopefully address all these issues. Thanks a lot for all these comments, have a nice day, -- Fabien Coelho - coelho@cri.ensmp.fr
Patch withdrawn by author. --------------------------------------------------------------------------- Fabien COELHO wrote: > > Dear patchers, > > Please find attached version number 3 for a patch to enable extensions > such as contribs or external add-ons to be installed simply with an > already installed postgresql. > > This version addresses Peter's comments about src/makefiles/Makefile.* > that do not need to be installed. It works for me, as previous versions. > > See other comments in previous submissions and responses. > > -- > Fabien. Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- 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