From: Alvaro Herrera on
Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010:

> We could try to make this a supported build arrangement, but I'm
> inclined to think that a cleaner solution is to split out the loadable
> module as a separate contrib subdirectory. Thoughts?

Do you mean contrib/pg_upgrade/somelib? If so, +1. If you instead mean
putting the library in contrib/somelib, I'm not so sure that it's
cleaner than trying to support executable+shared lib in a single contrib
module.
--

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
Alvaro Herrera <alvherre(a)alvh.no-ip.org> writes:
> Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010:
>> We could try to make this a supported build arrangement, but I'm
>> inclined to think that a cleaner solution is to split out the loadable
>> module as a separate contrib subdirectory. Thoughts?

> Do you mean contrib/pg_upgrade/somelib? If so, +1.

Hmm. I had been thinking the other way, but I'll see if that can be
made to work.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andrew Dunstan on


Tom Lane wrote:
> Alvaro Herrera <alvherre(a)alvh.no-ip.org> writes:
>
>> Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010:
>>
>>> We could try to make this a supported build arrangement, but I'm
>>> inclined to think that a cleaner solution is to split out the loadable
>>> module as a separate contrib subdirectory. Thoughts?
>>>
>
>
>> Do you mean contrib/pg_upgrade/somelib? If so, +1.
>>
>
> Hmm. I had been thinking the other way, but I'll see if that can be
> made to work.
>
>
>

Not sure this will work on its own with the MSVC build system - I don't
think it's set up for sub-modules. But we can finessee that if
necessary, just as we make special provision for pgcrypto.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
Andrew Dunstan <andrew(a)dunslane.net> writes:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre(a)alvh.no-ip.org> writes:
>>> Do you mean contrib/pg_upgrade/somelib? If so, +1.
>>
>> Hmm. I had been thinking the other way, but I'll see if that can be
>> made to work.

> Not sure this will work on its own with the MSVC build system - I don't
> think it's set up for sub-modules.

Oh, right. Since the entire point here is to *not* require new
buildsystem infrastructure for pg_upgrade, I'm back to thinking that
a separate contrib module is the way to go.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Bruce Momjian on
Tom Lane wrote:
> A look at the MSVC buildfarm members shows that they are not building
> most of the files added to contrib/pg_upgrade. The reason seems to be
> that that module tries to build both an executable program *and* a
> shared library, which it does by dint of setting both PROGRAM and
> MODULES in its Makefile. Now that is a dirty hack that is nowhere
> documented to work, and in fact the pgxs documentation explicitly says
> not to do that. It accidentally fails to fail, at the moment, because
> of the way pgxs.mk is set up, and because the OBJS variable is only
> needed for one of these targets. But the MSVC build scripts aren't
> expecting this and evidently disregard PROGRAM after they see MODULES.

Yeah, I was stumped by the problem of creating an executable and shared
object and didn't find any usage of this case. Leave it me to find a
loop-hole. ;-)

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers