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