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?