Re: Compiling extensions on Windows

Hi all

Out of personal interest (in pain and suffering) I was recently looking
into how to compile extensions out-of-tree on Windows using Visual
Studio (i.e. no PGXS).

It looks like the conventional answer to this is "Do a source build of
PG, compile your ext in-tree in contrib/, and hope the result is binary
compatible with release PostgreSQL builds for Windows". Certainly that's
how I've been doing it to date.

How about everyone else here? Does anyone actually build and distribute
extensions out of tree at all?

I'm interested in making the Windows installer distributions a bit more
extension dev friendly. In particular, I'd really like to see EDB's
Windows installers include the libintl.h for the included libintl, since
its omission, combined with Pg being built with ENABLE_NLS, tends to
break things horribly. Users can always undefine ENABLE_NLS, but it's an
unnecessary roadblock.

Are there any objections from -hackers to including 3rd party headers
for libs we expose in our public headers in the binary distribution?

Other than bundling 3rd party headers, any ideas/suggestions for how we
might make ext building saner on Windows?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On 01/05/2014 10:32 PM, Craig Ringer wrote:
> Hi all
>
> Out of personal interest (in pain and suffering) I was recently looking
> into how to compile extensions out-of-tree on Windows using Visual
> Studio (i.e. no PGXS).
>
> It looks like the conventional answer to this is "Do a source build of
> PG, compile your ext in-tree in contrib/, and hope the result is binary
> compatible with release PostgreSQL builds for Windows". Certainly that's
> how I've been doing it to date.
>
> How about everyone else here? Does anyone actually build and distribute
> extensions out of tree at all?
>
> I'm interested in making the Windows installer distributions a bit more
> extension dev friendly. In particular, I'd really like to see EDB's
> Windows installers include the libintl.h for the included libintl, since
> its omission, combined with Pg being built with ENABLE_NLS, tends to
> break things horribly. Users can always undefine ENABLE_NLS, but it's an
> unnecessary roadblock.
>
> Are there any objections from -hackers to including 3rd party headers
> for libs we expose in our public headers in the binary distribution?
>
> Other than bundling 3rd party headers, any ideas/suggestions for how we
> might make ext building saner on Windows?
>

If you're bundling a DLL then I don't see why the corresponding header
file shouldn't be included also.

cheers

andrew

On Mon, Jan 6, 2014 at 3:32 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> Hi all
>
> Out of personal interest (in pain and suffering) I was recently looking
> into how to compile extensions out-of-tree on Windows using Visual
> Studio (i.e. no PGXS).
>
> It looks like the conventional answer to this is "Do a source build of
> PG, compile your ext in-tree in contrib/, and hope the result is binary
> compatible with release PostgreSQL builds for Windows". Certainly that's
> how I've been doing it to date.
>
> How about everyone else here? Does anyone actually build and distribute
> extensions out of tree at all?
>
> I'm interested in making the Windows installer distributions a bit more
> extension dev friendly. In particular, I'd really like to see EDB's
> Windows installers include the libintl.h for the included libintl, since
> its omission, combined with Pg being built with ENABLE_NLS, tends to
> break things horribly. Users can always undefine ENABLE_NLS, but it's an
> unnecessary roadblock.

Sandeep, can you work on fixing this please?

Thanks.

> Are there any objections from -hackers to including 3rd party headers
> for libs we expose in our public headers in the binary distribution?
>
> Other than bundling 3rd party headers, any ideas/suggestions for how we
> might make ext building saner on Windows?
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sure. I'll make the changes so that the next available Windows installers
include lbintl.h in $Installdir/include. How about the changes with respect
to NLS?

On Mon, Jan 6, 2014 at 2:44 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> On Mon, Jan 6, 2014 at 3:32 AM, Craig Ringer <craig(at)2ndquadrant(dot)com>
> wrote:
> > Hi all
> >
> > Out of personal interest (in pain and suffering) I was recently looking
> > into how to compile extensions out-of-tree on Windows using Visual
> > Studio (i.e. no PGXS).
> >
> > It looks like the conventional answer to this is "Do a source build of
> > PG, compile your ext in-tree in contrib/, and hope the result is binary
> > compatible with release PostgreSQL builds for Windows". Certainly that's
> > how I've been doing it to date.
> >
> > How about everyone else here? Does anyone actually build and distribute
> > extensions out of tree at all?
> >
> > I'm interested in making the Windows installer distributions a bit more
> > extension dev friendly. In particular, I'd really like to see EDB's
> > Windows installers include the libintl.h for the included libintl, since
> > its omission, combined with Pg being built with ENABLE_NLS, tends to
> > break things horribly. Users can always undefine ENABLE_NLS, but it's an
> > unnecessary roadblock.
>
> Sandeep, can you work on fixing this please?
>
> Thanks.
>
> > Are there any objections from -hackers to including 3rd party headers
> > for libs we expose in our public headers in the binary distribution?
> >
> > Other than bundling 3rd party headers, any ideas/suggestions for how we
> > might make ext building saner on Windows?
> >
> > --
> > Craig Ringer http://www.2ndQuadrant.com/
> > PostgreSQL Development, 24x7 Support, Training & Services
> >
> >
> > --
> > Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

--
Sandeep Thakkar

On Mon, Jan 6, 2014 at 10:57 AM, Sandeep Thakkar
<sandeep(dot)thakkar(at)enterprisedb(dot)com> wrote:
> Sure. I'll make the changes so that the next available Windows installers
> include lbintl.h in $Installdir/include. How about the changes with respect
> to NLS?

No, there's nothing to change there. Craig was suggesting that users
could disable NLS in their extension to avoid issues with the missing
header, but that's not a good solution.

> On Mon, Jan 6, 2014 at 2:44 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>> On Mon, Jan 6, 2014 at 3:32 AM, Craig Ringer <craig(at)2ndquadrant(dot)com>
>> wrote:
>> > Hi all
>> >
>> > Out of personal interest (in pain and suffering) I was recently looking
>> > into how to compile extensions out-of-tree on Windows using Visual
>> > Studio (i.e. no PGXS).
>> >
>> > It looks like the conventional answer to this is "Do a source build of
>> > PG, compile your ext in-tree in contrib/, and hope the result is binary
>> > compatible with release PostgreSQL builds for Windows". Certainly that's
>> > how I've been doing it to date.
>> >
>> > How about everyone else here? Does anyone actually build and distribute
>> > extensions out of tree at all?
>> >
>> > I'm interested in making the Windows installer distributions a bit more
>> > extension dev friendly. In particular, I'd really like to see EDB's
>> > Windows installers include the libintl.h for the included libintl, since
>> > its omission, combined with Pg being built with ENABLE_NLS, tends to
>> > break things horribly. Users can always undefine ENABLE_NLS, but it's an
>> > unnecessary roadblock.
>>
>> Sandeep, can you work on fixing this please?
>>
>> Thanks.
>>
>> > Are there any objections from -hackers to including 3rd party headers
>> > for libs we expose in our public headers in the binary distribution?
>> >
>> > Other than bundling 3rd party headers, any ideas/suggestions for how we
>> > might make ext building saner on Windows?
>> >
>> > --
>> > Craig Ringer http://www.2ndQuadrant.com/
>> > PostgreSQL Development, 24x7 Support, Training & Services
>> >
>> >
>> > --
>> > Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>> > To make changes to your subscription:
>> > http://www.postgresql.org/mailpref/pgsql-hackers
>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>
>
>
> --
> Sandeep Thakkar
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/05/2014 07:32 PM, Craig Ringer wrote:
> Out of personal interest (in pain and suffering) I was recently
> looking into how to compile extensions out-of-tree on Windows using
> Visual Studio (i.e. no PGXS).
>
> It looks like the conventional answer to this is "Do a source build
> of PG, compile your ext in-tree in contrib/, and hope the result is
> binary compatible with release PostgreSQL builds for Windows".
> Certainly that's how I've been doing it to date.

Yes, this pretty much exactly describes how I build PL/R for Windows.
I had to match my build system SDK with the one EDB uses to get a
compatible binary. It would be nice if we had something equivalent to
PGXS on Windows, or maybe even a community build system where authors
could get Windows binaries built.

Joe

- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSytzOAAoJEDfy90M199hlgdUP/3wHL7Akq4ONkYlFXq8d3LGJ
h5LNAWvILfJVOI3dmpHHzw8FCmWSsrsnDKuN/GUvJvhioPL0QsWgU1YGLwKNb7Mt
Q3famk8hJCe8PikrL5KvItk1jQtxem+M4wGcKZZoM2cb4soeRDxM5FtTKzZMHGi0
9GA3Tx/TpgGfIP35Xg9ckL/LejyOZIndrRHuJHREGZlIP27AW0SEscZMDq25Q5yy
jPcWki7hAIABohwkRPkFWVZArhSrCe1dA1Yy0Gad5cB/JdVB4xAjkmwLSa2suBod
nQ65G/8Hz88GIRxY1FlzPn+06IDnSdnZmrhxfZLn8Vl/mnMoW9h6pKmBNyWTQMoP
25Ex5/tYIQ6iYyUO3Ic/B/23OMVHu9bWXeyk1hKEpqCFR/1BctzafQI/vA4dRs0u
KRN3hua9GYnX+guw+d9mIkujPAeXphbjaMlgY6ckkENmiAg1HXfzv8+tKsQT4Pwx
IqcSNzIsnzTRSag1IKklwUW6DuTSGyFHyXsbWRA+kkxL2/ucHL7f2mCmbZ3Qg8WW
zthp6dN+9dLC/iH92qiS/nkFFxkkikyBpG2wb+Xcc0Ko1u26xp3e7ZFnCUZQ0Bse
DTiOIywW89ICk7pokI8vMEwJIN5d42dZ01GL6XdLT9iPTnGXSuCQsE2GSMBxUuHs
KbY+hsZrrvWH0QaVkrq5
=V4H5
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2014 12:41 AM, Joe Conway wrote:
> Yes, this pretty much exactly describes how I build PL/R for
> Windows. I had to match my build system SDK with the one EDB uses
> to get a compatible binary. It would be nice if we had something
> equivalent to PGXS on Windows, or maybe even a community build
> system where authors could get Windows binaries built.

I'd be interested in hearing if you have any luck doing this with a
standlone MSVC build: .dll build type, no manifest, compile as C code,
appropriate include and lib paths, define WIN32, link to postgres.lib,
add PGDLLEXPORT to all declarations of functions with a
PG_FUNCTION_INFO_V1, build.

- --
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS01XNAAoJELBXNkqjr+S2S4QH/icetcqZDmsHFHjZnm3hY+LP
M0+rU8+E3on5V/JmWR3bBESmlYXRYM53LmgwapwCfQ45rsrMSiKACyxtl/XkWsEh
38NTsagjlZtsyZIiUoe9d0szSNQerS86ZDBwXAvJnBSNLQy1AnDQ5tzsFbdeZph4
veL6MnoKNIacfbkEBoCjM0KyYdjnYnt4nRlmbGKQNg/h4Y9KqgJsFFpk0r8dfz+v
KNPPyOmdHIcMyCgJS9hIdAdzc+CPPjYBZC3oVVQAuIOsqccmTykPr4Nh3MVcSfCy
JJTRZhzgU6TdRZIi4adY8Ys39O+TJM2T5Wr1xJ6+Eapnd6L1AiY/08jbZIrsFVc=
=5/Y6
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/12/2014 06:56 PM, Craig Ringer wrote:
> On 01/07/2014 12:41 AM, Joe Conway wrote:
>> Yes, this pretty much exactly describes how I build PL/R for
>> Windows. I had to match my build system SDK with the one EDB
>> uses to get a compatible binary. It would be nice if we had
>> something equivalent to PGXS on Windows, or maybe even a
>> community build system where authors could get Windows binaries
>> built.
>
> I'd be interested in hearing if you have any luck doing this with
> a standlone MSVC build: .dll build type, no manifest, compile as C
> code, appropriate include and lib paths, define WIN32, link to
> postgres.lib, add PGDLLEXPORT to all declarations of functions with
> a PG_FUNCTION_INFO_V1, build.

Yes, that's more-or-less how I do it. I checked with EDB to be sure I
had the same SDK (looks like last time I did it it was SDK 7.1), then I:

1) download postgres source
2) copy plr source into contrib directory
3) modify src/tools/msvc/* to make plr look like any other contrib
4) build

As long as the SDK is matched, the resulting plr.dll works fine with
the EDB one-click installer version of postgres (or at least so far).

Joe

- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS01m8AAoJEDfy90M199hlkPEP/A1iCDJeRchfBM4OQB73k0VN
+4o9aVxo3n4jjoOiKI3zctpP6bHQI9/wyI9OYAKnRr3PutttrEyDn1MO3wBffTVN
k84rXyKKROgZOnGpQrE33QG82J1TRHmxZRyeQirQplekWEsB2RpiGu+jZJDjUsLn
svmgPZOka5tc+KqC4OJ3qXprv5OW4h6xMfZmUljn6jdzsuEubE6p4X/XqqGUJmVP
t6caIJ3yKvIcedQ7QZmxWEJXYGGoKlr6qv2Vo99SfqK9lGX6A7DFwAG3DaLmWqa/
rULapnfnET5jUtfncu3zkz6Kok848BsoaSfFZpHyyzvU2RlfAAPWCv0ZnNrSYTsl
s7blVBzanBoX63gy4MwMOcGdHmjPyYjeJ78m53GE28cvv62JEGubISkWoCbmOPYu
+UmxaCPR1l03n/QAv3Qo0fCEtU09OXzYci8NDEKqbdkWt9K/M4bNlv207J0CywiX
pEwQGVciaR5ylKYFZpKpCpgf6OElBVFaUk8uE41swgxM3McXWoPFuKocnhTWd0u6
9Fyb7W8W2kAJeOkiNWcpsX2DNHKMkZ8siTfMufyqHDxVfaJLie/0oTZejnGJf4Lh
vOBpqxdowN6xVhBR796vtzxjLg50vDj8NzOKvn6evtJMnWJkUiRBsY8JrR6g3fII
lb+3NTRa5x0ptApbsUKJ
=wFy+
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2014 11:13 AM, Joe Conway wrote:

> Yes, that's more-or-less how I do it. I checked with EDB to be sure
> I had the same SDK (looks like last time I did it it was SDK 7.1),
> then I:
>
> 1) download postgres source 2) copy plr source into contrib
> directory

What I mean is that you should not need a full Pg build tree to
compile extensions. Just as we use PGXS on *nix, so it is possible to
just use Visual Studio to build the extension on Windows as a VS
project like any other.

> As long as the SDK is matched, the resulting plr.dll works fine
> with the EDB one-click installer version of postgres (or at least
> so far).

The SDK shouldn't even need to match. Windows software is expected to
cope with mismatched, mix-and-match C runtimes. Icky, but occasionally
useful.

So long as you don't pass a FILE* across DLL boundaries, or free()
memory that was malloc()'d in another DLL, mixing runtimes should work
fine. I'd be interested in knowing what problems you encountered when
the runtime didn't match.

Maybe it's specific to how we do build within a Pg source tree? I was
able to use three different SDK builds against EDB's latest 9.3
packages - SDK 7.1 (x86 and x64), toolchain v90 (x86), and toolchain
v100 (x86) - to compile and test a moderately trivial extension.

- --
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS01vxAAoJELBXNkqjr+S2zcoIAI75MetuO+osAlSOMdMDAgKh
7rqKu8VPyF2bjFVAiYdZOS9Yvlg3yZDzEG2JMbUSJOz3KtGIirZkIub8hgI4q4/W
6PBg5UZAiwK30AXILTqGBXio/Z+olbCPOKvcVv05OF4WExYLMek5Hc2SKy3UIudj
HHvC10LkSeVvJvNj+rK7SUjQIpwa4a2+cc0gx87z7kd8ElVwJ3D/c1Eb3DM8mdsg
KqIlmWkGolwnk1fb/JoabkO9XVvRjPgpj/aR9Ak6mUH7QTXGMqafdpPeCV9BhGRK
d6MDDT3ncoEzHZd7GsKeqVWBFz9eZ7hLXiQR6rZ7bidvNVc4V7NnM2dr50uhoec=
=pgpf
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/12/2014 07:22 PM, Craig Ringer wrote:
> On 01/13/2014 11:13 AM, Joe Conway wrote: What I mean is that you
> should not need a full Pg build tree to compile extensions. Just as
> we use PGXS on *nix, so it is possible to just use Visual Studio to
> build the extension on Windows as a VS project like any other.

I have never gotten that to work.

>> As long as the SDK is matched, the resulting plr.dll works fine
>> with the EDB one-click installer version of postgres (or at
>> least so far).
>
> The SDK shouldn't even need to match. Windows software is expected
> to cope with mismatched, mix-and-match C runtimes. Icky, but
> occasionally useful.

Unfortunately my experience tells me otherwise. Mismatched SDK =
plr.dll that does not work correctly with EDB builds of postgres.

> So long as you don't pass a FILE* across DLL boundaries, or free()
> memory that was malloc()'d in another DLL, mixing runtimes should
> work fine. I'd be interested in knowing what problems you
> encountered when the runtime didn't match.

plr would not load. I'm not good enough with MSVC and Windows
debuggers to figure out why, and don't have the time or interest to
become so, I just know matching the SDK to the postgres build resulted
in it owrking for me and no more complaints of this type from the
field. It would work fine with the postgres build I made, but not with
the EDB build which of course is what virtually everyone running pg on
Windows uses.

> Maybe it's specific to how we do build within a Pg source tree? I
> was able to use three different SDK builds against EDB's latest
> 9.3 packages - SDK 7.1 (x86 and x64), toolchain v90 (x86), and
> toolchain v100 (x86) - to compile and test a moderately trivial
> extension.

Trivial is probably the key thing. With PL/R it also has to link
against the R.dll which is built with yet another toolchain on Windows.

Joe

- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS018UAAoJEDfy90M199hl/mAP/2OhXbvrlKSzP6fWi8g9Tez0
PnWaOFXXPIeOi5lJ/o5rC7HrQdiCCBljSBAffq0PKl8SVn2cDwmA5E2n4T3JfZQF
PYGZiYuqoiZ6i+svW7x6XocDnIhJgMJvTvys7ToApjmkD3VEgj7RO8MHQyYmVDsh
A9WIPpyb96mTmzlTLnHZDkfL7MgEof4kTHHC2jOa6i3wMq+zATc6lBTXOcrrGzS8
qd/iIap0kNdwKgLEX/jXip0YOB8SMfxOeHVLV+790JUwnWmBJnbn3XDqFEmj39kK
dGEP8vaxjPppyEmMvkGZd5Hxw6WIGFASTjyn6kXH1VfVqsLNZYO+rwTXnSVtyqH0
aFCKLT7awMBjFSh3plFQcqxeeqElZZaCRNVO5xooQ28xoUoUl/wVYqI0yoF9hKKm
NlJ8jJGB6aEImFlQ7QUg2eZRfMpyYc9J06uaX1+/L3g71O4O2Xzgc6gPVWvYCIQP
BvcNBtUlxA38H5wjiMSlyyz4Si95cIIbqDfUliKZ1Ab0W24en0vnvISxk6v/2GKc
vE9X7GRFUjmUJNoIvkRu0hnzp5S955sO0X6Q6pDmgM2esGRADMTntY0Bcxp8R2qg
qiZkVs1vfuewLmzz4LqixItW9BhMHK3zdGcv07xntNt+EAaz8g3cU5tBZP8CP6y8
JTa/fyFth7hL+ttkH5hc
=9+nY
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2014 11:35 AM, Joe Conway wrote:
> On 01/12/2014 07:22 PM, Craig Ringer wrote:
>> On 01/13/2014 11:13 AM, Joe Conway wrote: What I mean is that
>> you should not need a full Pg build tree to compile extensions.
>> Just as we use PGXS on *nix, so it is possible to just use Visual
>> Studio to build the extension on Windows as a VS project like any
>> other.
>
> I have never gotten that to work.
>
>>> As long as the SDK is matched, the resulting plr.dll works fine
>>> with the EDB one-click installer version of postgres (or at
>>> least so far).
>
>> The SDK shouldn't even need to match. Windows software is
>> expected to cope with mismatched, mix-and-match C runtimes. Icky,
>> but occasionally useful.
>
> Unfortunately my experience tells me otherwise. Mismatched SDK =
> plr.dll that does not work correctly with EDB builds of postgres.

Something for me to play with once this CF is over, then.

- --
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS01/mAAoJELBXNkqjr+S2ZQcH/0rHjCW+6pvg8727dJHSmYfM
fY18VBlgYzjfzgPaFLYgp4OqT7VHl2h1d7AapVo8wRblVD4z1hEFtW6/j56Mx1wm
UTw7rWhs7utA9G+gzWcHJz9VDxED0ROFH+IwurSM85P57ztPKaRhvp6YT3fibhYb
kqw51FrEfvlnhCMi3Art3DGmHtzDRLwGTI03YOr/GRfWsccHPwpRLkpQkyuMsyOX
UBhPenz0OhtkVxEfFSmyVWmu6NzlOQyxgFgl8zW7R9pq4fTBgOfo198RDkGKnCno
9KYq3H8VqLxHgpyR2KP3netrqDvDBzk0xVmgoaJbQyT6HyuQDWH6lIHE+5RTyyM=
=nreR
-----END PGP SIGNATURE-----

Craig Ringer wrote:
> Out of personal interest (in pain and suffering) I was recently looking
> into how to compile extensions out-of-tree on Windows using Visual
> Studio (i.e. no PGXS).
>
> It looks like the conventional answer to this is "Do a source build of
> PG, compile your ext in-tree in contrib/, and hope the result is binary
> compatible with release PostgreSQL builds for Windows". Certainly that's
> how I've been doing it to date.
>
> How about everyone else here? Does anyone actually build and distribute
> extensions out of tree at all?

I build binaries for oracle_fdw for EDB's binaries "by hand",
i.e. I look at what PGXS does on Linux and try to do something
comparable with "cl". It's rather painful, and something like
PGXS for MSVC would be very welcome.

Yours,
Laurenz Albe