Re: plPHP and plRuby

Peter Eisentraut wrote:

>Andrew Dunstan wrote:
>
>
>>But the reasons that applied to PL/Java (masses of non-C code was the
>>main one) probably don't apply in these 2 cases.
>>
>>
>
>I don't think it's the amount of non-C code; it's the amount of code
>that no one understands. Plus, an argument *for* inclusion was build
>farm coverage, which I understand will be solved in a different way,
>applicable to all external modules. Another argument was buzzword
>compliance, which doesn't apply to these two new candidates. So in
>summary, while I have not seen any valid reason for these inclusions,
>there continue to be some against it.
>
>
>

Well, I am not making any promises right now about when buildfarm will
support external modules.

My current thinking goes something like this:

. the config file will contain an extra stanza looking something like this:
addons => { <addonname> => { cvsrepo => "<repo locn>", module=>
"<modulename>" } ... }
. addons will be checked out at the same time as the core, but into a
separate directory. We will check them for recent mods in the same way
as the core.
. after we run "make installcheck" for the core we will run "make" for
each addon using the installed pgxs.
. after we run "make installcheck" for contrib we will run "make
installcheck" for each addon.

(Question - do we restrict addons to those that will build using pgxs?)

Happily, most of the webapp is agnostic about what is reported on -
probably adding one db field containing the addon names for the build
would suffice.

There are some odd wrinkles. For instance, construction of the URLs for
changed files will be somewhat harder. For that reason I think I am
going to insist at least in the first instance that all addons must be
hosted on pgfoundry where we know perfectly well how to construct cvsweb
URLs.There will undoubtedly be more when I get down to it. And we might
need to ignore addons for builds on stable branches up to and including
8.2 - I don't know yet.

Now, if someone feels like taking those ideas and running with them in
the buildfarm client code they are welcome to drop me a line and I can
add them to the project as a developer. Otherwise it will have to wait
till I get around to it. That's likely to be some way well into the 8.3
development cycle at the earliest.

And lastly, if we are not going to include these in core, I repeat what
I said before: we need to undertake some *serious* evangelising to major
packagers to get them to build more than just the core among their
standard packages.

cheers

andrew