Hi David,

No pain with CMake. It's pretty easy to use it in Windows for PostgreSQL
extensions. Example, https://github.com/dmitigr/pgnso


On Fri, 12 Jun 2020, 01:43 David Rowley, <dgrowle...@gmail.com> wrote:

> 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
>
>

Reply via email to