Обсуждение: Building PostgreSQL extensions on Windows

Hi,

I've heard from a few people that building PostgreSQL extensions on
Windows is a bit of a pain. I've heard from these people that their
solution was to temporarily add their extension as a contrib module
and have the extension building code take care of creating and
building the Visual Studio project file.

I also have to say, I do often use Visual Studio myself for PostgreSQL
development, but when it comes to testing something with an extension,
I've always avoided the problem and moved over to Linux.

I thought about how we might improve this situation.  The easiest way
I could think to do this was to just reuse the code that builds the
Visual Studio project files for contrib modules and write a Perl
script which calls those functions. Now, these functions, for those
who have never looked there before, they do use the PGXS compatible
Makefile as a source of truth and build the VS project file from that.
I've attached a very rough PoC patch which attempts to do this.

The script just takes the directory of the Makefile as the first
argument, and optionally the path to pg_config.exe as the 2nd
argument.  If that happens to be in the PATH environment variable then
that can be left out.

You end up with:

X:\pg_src\src\tools\msvc>perl extbuild.pl
X:\pg_src\contrib\auto_explain X:\pg\bin
Makefile dir         = X:\pg_src\contrib\auto_explain
Postgres include dir = X:\pg\include
Building             = Release
Detected hardware platform: x64

...

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.13

For now, I've only tested this on a few contrib modules. It does need
more work to properly build ones with a list of "MODULES" in the
Makefile. It seems to work ok on the MODULE_big ones that I tested. It
needs a bit more work to get the resource file paths working properly
for PROGRAM.

Before I go and invest more time in this, I'd like to get community
feedback about the idea. Is this something that we'd want? Does it
seem maintainable enough to have in core?  Is there a better way to do
it?

David

On 6/11/20 6:42 PM, David Rowley wrote:
> I've heard from a few people that building PostgreSQL extensions on
> Windows is a bit of a pain. I've heard from these people that their
> solution was to temporarily add their extension as a contrib module
> and have the extension building code take care of creating and
> building the Visual Studio project file.


Yep -- that is exactly how I have been building PL/R on Windows for many years,
and it is painful.


> I thought about how we might improve this situation.  The easiest way
> I could think to do this was to just reuse the code that builds the
> Visual Studio project files for contrib modules and write a Perl
> script which calls those functions. Now, these functions, for those
> who have never looked there before, they do use the PGXS compatible
> Makefile as a source of truth and build the VS project file from that.
> I've attached a very rough PoC patch which attempts to do this.
>
> The script just takes the directory of the Makefile as the first
> argument, and optionally the path to pg_config.exe as the 2nd
> argument.  If that happens to be in the PATH environment variable then
> that can be left out.
>
> You end up with:
>
> X:\pg_src\src\tools\msvc>perl extbuild.pl
> X:\pg_src\contrib\auto_explain X:\pg\bin
> Makefile dir         = X:\pg_src\contrib\auto_explain
> Postgres include dir = X:\pg\include
> Building             = Release
> Detected hardware platform: x64
>
> ...
>
> Build succeeded.
>     0 Warning(s)
>     0 Error(s)
>
> Time Elapsed 00:00:01.13
>
> For now, I've only tested this on a few contrib modules. It does need
> more work to properly build ones with a list of "MODULES" in the
> Makefile. It seems to work ok on the MODULE_big ones that I tested. It
> needs a bit more work to get the resource file paths working properly
> for PROGRAM.
>
> Before I go and invest more time in this, I'd like to get community
> feedback about the idea. Is this something that we'd want? Does it
> seem maintainable enough to have in core?  Is there a better way to do
> it?


Sounds very useful to me -- I'll give it a try with PL/R this weekend.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development