Remove MSVC scripts from the tree

On 22.09.23 03:12, Michael Paquier wrote:

It has been mentioned a few times now that, as Meson has been
integrated in the tree, the next step would be to get rid of the
custom scripts in src/tools/msvc/ and moving forward only support
Meson when building with VS compilers.

First we need to fix things so that we can build using meson from a
distribution tarball, which is the subject of
<https://commitfest.postgresql.org/44/4357/&gt;.

On Fri, Sep 22, 2023 at 08:06:57AM +0200, Peter Eisentraut wrote:

First we need to fix things so that we can build using meson from a
distribution tarball, which is the subject of
<https://commitfest.postgresql.org/44/4357/&gt;.

Thanks, missed this one.
--
Michael

On 2023-09-21 Th 21:12, Michael Paquier wrote:

As of today, I can see that the only buildfarm members relying on
these scripts are bowerbird and hamerkop, so these two would fail if
the patch attached were to be applied today. I am adding Andrew
D. and the maintainers of hamerkop (SRA-OSS) in CC for comments.

Changing bowerbird to use meson should not be difficult, just needs some
TUITs.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

On Fri, 22 Sep 2023 10:12:29 +0900
Michael Paquier <michael@paquier.xyz> wrote:

As of today, I can see that the only buildfarm members relying on
these scripts are bowerbird and hamerkop, so these two would fail if
the patch attached were to be applied today. I am adding Andrew
D. and the maintainers of hamerkop (SRA-OSS) in CC for comments.

hamerkop is not yet prepared for Meson builds, but we plan to work on this support soon.
If we go with Meson builds exclusively right now, we will have to temporarily remove the master/HEAD for a while.

Best Regards.
--
SRA OSS LLC
Chen Ningwei<chen@sraoss.co.jp>

On 2023-09-26 Tu 01:25, NINGWEI CHEN wrote:

On Fri, 22 Sep 2023 10:12:29 +0900
Michael Paquier<michael@paquier.xyz> wrote:

As of today, I can see that the only buildfarm members relying on
these scripts are bowerbird and hamerkop, so these two would fail if
the patch attached were to be applied today. I am adding Andrew
D. and the maintainers of hamerkop (SRA-OSS) in CC for comments.

hamerkop is not yet prepared for Meson builds, but we plan to work on this support soon.
If we go with Meson builds exclusively right now, we will have to temporarily remove the master/HEAD for a while.

Best Regards.

I don't think we should switch to that until you're ready.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

On 22.09.23 03:12, Michael Paquier wrote:

It has been mentioned a few times now that, as Meson has been
integrated in the tree, the next step would be to get rid of the
custom scripts in src/tools/msvc/ and moving forward only support
Meson when building with VS compilers. As far as I understand, nobody
has sent a patch to do that yet, so here is one.

Please find attached a patch to move the needle in this sense.

Your patch still leaves various mentions of Mkvcbuild.pm and Project.pm
in other files, including in

config/perl.m4
meson.build
src/bin/pg_basebackup/Makefile
src/bin/pgevent/meson.build
src/common/Makefile
src/common/meson.build
src/interfaces/libpq/Makefile
src/port/Makefile

A few of these comments are like "see $otherfile for the reason", which
means that if we delete $otherfile, we should move that information to a
new site somehow.

On Fri, Sep 29, 2023 at 11:26:55AM +0200, Peter Eisentraut wrote:

Your patch still leaves various mentions of Mkvcbuild.pm and Project.pm in
other files, including in

Indeed, thanks. I didn't think to check for references to these
modules.

config/perl.m4

Here is the thing:
# switches for symbols not beginning with underscore. Some exceptions are the
# Windows-specific -D_USE_32BIT_TIME_T and -D__MINGW_USE_VC2005_COMPAT; see
# Mkvcbuild.pm for details.

And we'd lose quite some information here. meson.build loops back to
perl.m4 for this part. Reformating the comments perl.m4 should do the
job.

meson.build

These were in Project::_new() and WriteItemDefinitionGroup(). Just
removing the reference does not remove any information.

src/bin/pg_basebackup/Makefile

-# If you add or remove files here, also update Mkvcbuild.pm, which only knows
-# about OBJS, not BBOBJS, and thus has to be manually updated to stay in sync
-# with this list.
This can be removed, I guess.

src/bin/pgevent/meson.build

The reference can be removed. The original says nothing about the use
of DisableLinkerWarnings() in this case.

src/common/Makefile
src/common/meson.build

These two have the same copy-pasted comment, and the reference can be
removed.

src/interfaces/libpq/Makefile

Can be removed once the MSVC files are gone.

src/port/Makefile

Can be removed.

Attached is a v2 with these adjustments, for now.
--
Michael

On 02.10.23 09:38, Michael Paquier wrote:

Attached is a v2 with these adjustments, for now.

General comments:

- I think we can't just delete install-windows.sgml. Some of that
content needs to be moved over to installation.sgml. As a simple
example, install-windows.sgml shows which MSVC versions are supported.
That information should surely be kept.

- Is src/backend/utils/README.Gen_dummy_probes still correct after this?
AFAICT, the Perl-based MSVC build system uses Gen_dummy_probes.pl, but
the meson build uses Gen_dummy_probes.sed even on Windows. Is that
correct, intended?

- src/port/pgstrsignal.c contains a comment that it is not "built in
MSVC builds", but AFAICT, that is only correct for the legacy Perl-based
build system, not for meson. Again, is that correct, intended?

Detail comments:

(Btw., whatever orderfile you used for the diff, I find that confusing.)

* config/perl.m4: This now contains all the required information, but
maybe break the text into paragraphs a bit?

* doc/src/sgml/installation.sgml:

I think this paragraph should just be removed altogether:

   <para>
    If you are building <productname>PostgreSQL</productname> for Microsoft
-  Windows, read this chapter if you intend to build with MinGW or Cygwin;
-  but if you intend to build with Microsoft's <productname>Visual
-  C++</productname>, see <xref linkend="install-windows"/> instead.
+  Windows, read this chapter if you intend to build with Meson, MinGW or
+  Cygwin.
   </para>

Here

     <para>
      PostgreSQL can be built using Cygwin, a Linux-like environment for
      Windows, but that method is inferior to the native Windows build
-    <phrase condition="standalone-ignore">(see <xref 
linkend="install-windows"/>)</phrase> and
-    running a server under Cygwin is no longer recommended.
+    with Meson, and running a server under Cygwin is no longer recommended.
     </para>

I think "with Meson" should be removed. The tradeoff is Cygwin vs.
native, it doesn't have anything to do with Meson.

Also, I think this paragraph needs a complete revision, along with
however install-windows.sgml gets integrated:

<para>
- PostgreSQL for Windows can be built using MinGW, a Unix-like build
[...]

* meson.build: I think these comments are unnecessary and can be removed:

-# From Project.pm
+# MSVC flags

+ # Preprocessor definitions.

* src/bin/pgevent/meson.build: After consideration, I think this
comment should just be removed:

-# FIXME: copied from Mkvcbuild.pm, but I don't think that's the right 
approach
+# FIXME: this may not not the right approach..

The original site in Mkvcbuild.pm does not contain a comment, so we
should accept that as canonical. It doesn't help much if we carry
around a comment like "this might be wrong" indefinitely without any
further supporting material.

* src/common/Makefile and src/common/meson.build: This change is losing
the period at the end of the first sentence:

  # A few files are currently only built for frontend, not server
-# (Mkvcbuild.pm has a copy of this list, too).  logging.c is excluded
-# from OBJS_FRONTEND_SHLIB (shared library) as a matter of policy,
-# because it is not appropriate for general purpose libraries such
-# as libpq to report errors directly.
+# logging.c is excluded from OBJS_FRONTEND_SHLIB (shared library) as
+# a matter of policy, because it is not appropriate for general purpose
+# libraries such as libpq to report errors directly.

On Thu, Oct 05, 2023 at 09:38:51AM +0200, Peter Eisentraut wrote:

- I think we can't just delete install-windows.sgml. Some of that content
needs to be moved over to installation.sgml. As a simple example,
install-windows.sgml shows which MSVC versions are supported. That
information should surely be kept.

I've been thinking about the whole structure for a bit, but with the
MSVC scripts gone and the fact that we would rely on meson, moving
this information to the section under the platform-specific notes is
feeling kind of natural here. Here is a possible split of the
information across several sections:
- The requirements:
-- ActiveState Perl could be entirely removed, IMO. Perhaps we should
replace that to a reference to raspberry-perl, chocolatey or similar?
I am not sure about the best approach here, so for now I've kept the
bits about active perl.
-- bison and flex, which would become hard requirements on Windows
with Visual Studio now. Perhaps this could be unified with the patch
for distprep later on, but here we have specifics for Windows.
-- All the other optional requirements, tcl, etc.
- MinGW notes.
- Visual Studio notes, with the versions of visual supported, download
links, and a bit more.
- Notes specific about 64b builds.

The attached is a bit crude and requires adjustments, but it shows the
idea.

- Is src/backend/utils/README.Gen_dummy_probes still correct after this?
AFAICT, the Perl-based MSVC build system uses Gen_dummy_probes.pl, but the
meson build uses Gen_dummy_probes.sed even on Windows. Is that correct,
intended?

Interesting point. This may depend on the environment at the end? As
far as I can see, sed is currently a hard requirement in the meson
build and we'd fail if the command cannot be used. The buildfarm
machines that test meson are able to find sed, making
Gen_dummy_probes.pl not necessary:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=drongo&amp;dt=2023-10-11%2020%3A21%3A17&amp;stg=configure

So the $1000 question is: could there be a point in keeping the perl
script around if sed cannot be found? The buildfarm coverage is
currently saying no thanks to chocolatey, at least. The VM images
compiled by Andres for the CI seem to have the same opinion.

- src/port/pgstrsignal.c contains a comment that it is not "built in MSVC
builds", but AFAICT, that is only correct for the legacy Perl-based build
system, not for meson. Again, is that correct, intended?

Indeed, it's built under meson for WIN32. Good find.

Detail comments:

(Btw., whatever orderfile you used for the diff, I find that confusing.)

Here is my configuration for that:
https://github.com/michaelpq/home/blob/main/.gitconfig_orderfile

* config/perl.m4: This now contains all the required information, but maybe
break the text into paragraphs a bit?

Sure. I've attempted something here.

* doc/src/sgml/installation.sgml:

I think this paragraph should just be removed altogether:

<para>
If you are building <productname>PostgreSQL</productname> for Microsoft
-  Windows, read this chapter if you intend to build with MinGW or Cygwin;
-  but if you intend to build with Microsoft's <productname>Visual
-  C++</productname>, see <xref linkend="install-windows"/> instead.
+  Windows, read this chapter if you intend to build with Meson, MinGW or
+  Cygwin.
</para>

Okay.

Here

<para>
PostgreSQL can be built using Cygwin, a Linux-like environment for
Windows, but that method is inferior to the native Windows build
-    <phrase condition="standalone-ignore">(see <xref
linkend="install-windows"/>)</phrase> and
-    running a server under Cygwin is no longer recommended.
+    with Meson, and running a server under Cygwin is no longer recommended.
</para>

I think "with Meson" should be removed. The tradeoff is Cygwin vs. native,
it doesn't have anything to do with Meson.

Okay.

Also, I think this paragraph needs a complete revision, along with however
install-windows.sgml gets integrated:

<para>
- PostgreSQL for Windows can be built using MinGW, a Unix-like build
[...]

Sure, see above for details.

* meson.build: I think these comments are unnecessary and can be removed:

-# From Project.pm
+# MSVC flags

+ # Preprocessor definitions.

Okay.

* src/bin/pgevent/meson.build: After consideration, I think this comment
should just be removed:

-# FIXME: copied from Mkvcbuild.pm, but I don't think that's the right
approach
+# FIXME: this may not not the right approach..

The original site in Mkvcbuild.pm does not contain a comment, so we should
accept that as canonical. It doesn't help much if we carry around a comment
like "this might be wrong" indefinitely without any further supporting
material.

Hmm, okay. I was not sure about this one but fine for me to drop it.

* src/common/Makefile and src/common/meson.build: This change is losing the
period at the end of the first sentence:

# A few files are currently only built for frontend, not server
-# (Mkvcbuild.pm has a copy of this list, too).  logging.c is excluded
-# from OBJS_FRONTEND_SHLIB (shared library) as a matter of policy,
-# because it is not appropriate for general purpose libraries such
-# as libpq to report errors directly.
+# logging.c is excluded from OBJS_FRONTEND_SHLIB (shared library) as
+# a matter of policy, because it is not appropriate for general purpose
+# libraries such as libpq to report errors directly.

Fixed.
--
Michael

On 12.10.23 07:23, Michael Paquier wrote:

- Is src/backend/utils/README.Gen_dummy_probes still correct after this?
AFAICT, the Perl-based MSVC build system uses Gen_dummy_probes.pl, but the
meson build uses Gen_dummy_probes.sed even on Windows. Is that correct,
intended?

Interesting point. This may depend on the environment at the end? As
far as I can see, sed is currently a hard requirement in the meson
build and we'd fail if the command cannot be used. The buildfarm
machines that test meson are able to find sed, making
Gen_dummy_probes.pl not necessary:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=drongo&amp;dt=2023-10-11%2020%3A21%3A17&amp;stg=configure

So the $1000 question is: could there be a point in keeping the perl
script around if sed cannot be found? The buildfarm coverage is
currently saying no thanks to chocolatey, at least. The VM images
compiled by Andres for the CI seem to have the same opinion.

I don't think we should rely on sed being there on Windows. Maybe it's
true now on the handful of buildfarm/CI machines and early adopters, but
do we have any indication that that is systematic or just an accident?

Since we definitely require Perl now, we could just as well use the Perl
script and avoid this issue.

Attached is a Perl version of the sed script, converted by hand (so not
the super-verbose s2p thing). It's basically just the sed script with
semicolons added and the backslashes in the regular expressions moved
around. I think we could use something like that for all platforms now.

On 2023-11-08 We 03:41, Peter Eisentraut wrote:

On 12.10.23 07:23, Michael Paquier wrote:

- Is src/backend/utils/README.Gen_dummy_probes still correct after
this?
AFAICT, the Perl-based MSVC build system uses Gen_dummy_probes.pl,
but the
meson build uses Gen_dummy_probes.sed even on Windows.  Is that
correct,
intended?

Interesting point.  This may depend on the environment at the end?  As
far as I can see, sed is currently a hard requirement in the meson
build and we'd fail if the command cannot be used.  The buildfarm
machines that test meson are able to find sed, making
Gen_dummy_probes.pl not necessary:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=drongo&amp;dt=2023-10-11%2020%3A21%3A17&amp;stg=configure

So the $1000 question is: could there be a point in keeping the perl
script around if sed cannot be found?  The buildfarm coverage is
currently saying no thanks to chocolatey, at least.  The VM images
compiled by Andres for the CI seem to have the same opinion.

I don't think we should rely on sed being there on Windows.  Maybe
it's true now on the handful of buildfarm/CI machines and early
adopters, but do we have any indication that that is systematic or
just an accident?

Since we definitely require Perl now, we could just as well use the
Perl script and avoid this issue.

Attached is a Perl version of the sed script, converted by hand (so
not the super-verbose s2p thing).  It's basically just the sed script
with semicolons added and the backslashes in the regular expressions
moved around.  I think we could use something like that for all
platforms now.

I think it's alright, but please don't use literal tabs, use \t, even in
a character class.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On Wed, Nov 08, 2023 at 09:41:19AM +0100, Peter Eisentraut wrote:

I don't think we should rely on sed being there on Windows. Maybe it's true
now on the handful of buildfarm/CI machines and early adopters, but do we
have any indication that that is systematic or just an accident?

Or both? When doing builds based on MinGW in the past I vaguely
recall getting annoyed that I needed to look for sed as one thing, so
your suggestion could simplify the experience a bit.

Since we definitely require Perl now, we could just as well use the Perl
script and avoid this issue.

Attached is a Perl version of the sed script, converted by hand (so not the
super-verbose s2p thing). It's basically just the sed script with
semicolons added and the backslashes in the regular expressions moved
around. I think we could use something like that for all platforms now.

Sounds like a good idea to me now that perl is a hard requirement.
+1.
--
Michael

On 09.11.23 00:05, Michael Paquier wrote:

Attached is a Perl version of the sed script, converted by hand (so not the
super-verbose s2p thing). It's basically just the sed script with
semicolons added and the backslashes in the regular expressions moved
around. I think we could use something like that for all platforms now.

Sounds like a good idea to me now that perl is a hard requirement.
+1.

How about this patch as a comprehensive solution?

On Fri, Nov 10, 2023 at 08:38:21AM +0100, Peter Eisentraut wrote:

How about this patch as a comprehensive solution?
8 files changed, 26 insertions(+), 339 deletions(-)

Thanks for the patch. The numbers are here, and the patch looks
sensible.

The contents of probes.h without --enable-trace are exactly the same
before and after the patch.

In short, +1 to switch to what you are proposing here.
--
Michael

On 13.11.23 06:30, Michael Paquier wrote:

On Fri, Nov 10, 2023 at 08:38:21AM +0100, Peter Eisentraut wrote:

How about this patch as a comprehensive solution?
8 files changed, 26 insertions(+), 339 deletions(-)

Thanks for the patch. The numbers are here, and the patch looks
sensible.

The contents of probes.h without --enable-trace are exactly the same
before and after the patch.

In short, +1 to switch to what you are proposing here.

done

Other than the documentation details and the business about
Gen_dummy_probes, which has been dealt with separately, this patch looks
solid to me.

On 12.10.23 07:23, Michael Paquier wrote:

On Thu, Oct 05, 2023 at 09:38:51AM +0200, Peter Eisentraut wrote:

- I think we can't just delete install-windows.sgml. Some of that content
needs to be moved over to installation.sgml. As a simple example,
install-windows.sgml shows which MSVC versions are supported. That
information should surely be kept.

I've been thinking about the whole structure for a bit, but with the
MSVC scripts gone and the fact that we would rely on meson, moving
this information to the section under the platform-specific notes is
feeling kind of natural here. Here is a possible split of the
information across several sections:
- The requirements:
-- ActiveState Perl could be entirely removed, IMO. Perhaps we should
replace that to a reference to raspberry-perl, chocolatey or similar?
I am not sure about the best approach here, so for now I've kept the
bits about active perl.
-- bison and flex, which would become hard requirements on Windows
with Visual Studio now. Perhaps this could be unified with the patch
for distprep later on, but here we have specifics for Windows.
-- All the other optional requirements, tcl, etc.
- MinGW notes.
- Visual Studio notes, with the versions of visual supported, download
links, and a bit more.
- Notes specific about 64b builds.

The attached is a bit crude and requires adjustments, but it shows the
idea.

It's tricky. Eventually, we would like to reduce some of the
duplication, like the whole list of requirements. But there are some
Windows-specific details in there, so I don't know.

My suggestion would be:

Make a new <sect2 id="installation-notes-windows"> titled "Windows" at
the end of installation.sgml (after the Solaris section). Dump most of
the content from install-windows.sgml in there (except the stuff about
the old build system). Rename the existing section "MinGW/Native
Windows" to just "MinGW" and make some minor adjustments, similar to
your patch.

That way, we can move forward, and we can adjust and trim the details of
the documentation over time.

On Tue, Nov 14, 2023 at 11:18:52AM +0100, Peter Eisentraut wrote:

Other than the documentation details and the business about
Gen_dummy_probes, which has been dealt with separately, this patch looks
solid to me.

Thanks.

It's tricky. Eventually, we would like to reduce some of the duplication,
like the whole list of requirements. But there are some Windows-specific
details in there, so I don't know.

Yes, that's something I was considering but polluting the meson
dependency list with Windows-specific links was not the best way
forward to me, because there are few users who care about knowing
where Active Perl or an equivalent is located.

My suggestion would be:

Make a new <sect2 id="installation-notes-windows"> titled "Windows" at the
end of installation.sgml (after the Solaris section). Dump most of the
content from install-windows.sgml in there (except the stuff about the old
build system). Rename the existing section "MinGW/Native Windows" to just
"MinGW" and make some minor adjustments, similar to your patch.

That way, we can move forward, and we can adjust and trim the details of the
documentation over time.

The latest patch I have sent is close to that, actually. Instead of
creating a new section, I have integrated the contents of
install-windows.sgml into the existing section dedicated to MinGW and
native Windows because some parts apply to both of them, like the
crash reporting facility. So this gave the following structure:
- sect2 MinGW/Native Windows
-- sect3 Requirements
-- sect3 MinGW
-- sect3 Visual Studio
-- sect3 Special Considerations for 64-Bit Windows
-- sect3 Collecting Crash Dumps on Windows

The last parts affects both MinGW and VS builds, while the first
requirement part applies only to native (references to MinGW are only
there to handle dependencies for the builds). So I'm OK to live with
a bit of duplication across two sect2 rather than attempt to unify
them, while renaming the current MinGW/native section.

With the requirements and the SDK-related guidelines, all the
information seems from the original install-windows.sgml seems to be
around. Hopefully I did not miss a spot.

Attached is a v4. hamerkop and bowerbird still rely on that in the
buildfarm today.
--
Michael

On 15.11.23 05:49, Michael Paquier wrote:

Attached is a v4.

I'm happy with that.

(Note, however, that your rebase didn't pick up commits e7814b40d0 and
b41b1a7f49 that I did yesterday. Please check that again.)

Hi,

On 2023-11-15 13:49:06 +0900, Michael Paquier wrote:

The latest patch I have sent is close to that, actually. Instead of
creating a new section, I have integrated the contents of
install-windows.sgml into the existing section dedicated to MinGW and
native Windows because some parts apply to both of them, like the
crash reporting facility. So this gave the following structure:
- sect2 MinGW/Native Windows
-- sect3 Requirements
-- sect3 MinGW
-- sect3 Visual Studio
-- sect3 Special Considerations for 64-Bit Windows
-- sect3 Collecting Crash Dumps on Windows

It doesn't seem like your patch has it quite that way? I see

<sect2 id="installation-notes-mingw">
<title>MinGW</title>
...
<sect2 id="installation-notes-windows">
<title>Windows</title>

Where "Windows" actually seems to solely describe visual studio? That seems
confusing.

diff --git a/src/port/pgstrsignal.c b/src/port/pgstrsignal.c
index 7d76d1cca9..8c10a760c6 100644
--- a/src/port/pgstrsignal.c
+++ b/src/port/pgstrsignal.c
@@ -6,9 +6,6 @@
* On platforms compliant with modern POSIX, this just wraps strsignal(3).
* Elsewhere, we do the best we can.
*
- * This file is not currently built in MSVC builds, since it's useless
- * on non-Unix platforms.
- *
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*

Huh, so this was wrong since the code was added? For a moment I thought I'd
unintentionally promoted it to be built by default, but ...

index eca930ae47..14c9905b60 100644
--- a/src/bin/pgevent/meson.build
+++ b/src/bin/pgevent/meson.build
@@ -14,7 +14,6 @@ pgevent_sources += rc_bin_gen.process(win32ver_rc, extra_args: [

pgevent_sources += windows.compile_resources('pgmsgevent.rc')

-# FIXME: copied from Mkvcbuild.pm, but I don't think that's the right approach
pgevent_link_args = []
if cc.get_id() == 'msvc'
pgevent_link_args += '/ignore:4104'

I think it's worth leaving a trail indicating that adding this
warning-suppression is dubious at best. It seems to pretty obviously paper
over us exporting the symbols the wrong way:
https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4104?view=msvc-170

Which pretty clearly explains that pgevent.def is wrong.

I just can't really test it, nor does it have test. Otherwise I might have
fixed it.

@@ -53,10 +53,25 @@ AC_DEFUN([PGAC_CHECK_PERL_CONFIGS],
# would be fatal to try to compile PL/Perl to a different libc ABI than core
# Postgres uses.  The available information says that most symbols that affect
# Perl's own ABI begin with letters, so it's almost sufficient to adopt -D
-# switches for symbols not beginning with underscore.  Some exceptions are the
-# Windows-specific -D_USE_32BIT_TIME_T and -D__MINGW_USE_VC2005_COMPAT; see
-# Mkvcbuild.pm for details.  We absorb the former when Perl reports it.  Perl
-# never reports the latter, and we don't attempt to deduce when it's needed.
+# switches for symbols not beginning with underscore.
+
+# Some exceptions are the Windows-specific -D_USE_32BIT_TIME_T and
+# -D__MINGW_USE_VC2005_COMPAT. To be exact, Windows offers several 32-bit ABIs.
+# Perl is sensitive to sizeof(time_t), one of the ABI dimensions.  To get
+# 32-bit time_t, use "cl -D_USE_32BIT_TIME_T" or plain "gcc".  For 64-bit
+# time_t, use "gcc -D__MINGW_USE_VC2005_COMPAT" or plain "cl".  Before MSVC
+# 2005, plain "cl" chose 32-bit time_t.  PostgreSQL doesn't support building
+# with pre-MSVC-2005 compilers, but it does support linking to Perl built with
+# such a compiler.  MSVC-built Perl 5.13.4 and later report -D_USE_32BIT_TIME_T
+# in $Config{ccflags} if applicable, but MinGW-built Perl never reports
+# -D_USE_32BIT_TIME_T despite typically needing it.

Hm, it's pretty odd to have comments about cl.exe here, given that it can't
even be used with msvc.

My impression from testing this is that absorbing the flag from perl suffices
with strawberry perl and mingw perl, both when building with mingw and msvc.

+# Ignore the $Config{ccflags} opinion about -D_USE_32BIT_TIME_T, and use a
+# runtime test to deduce the ABI Perl expects.  Specifically, test use of
+# PL_modglobal, which maps to a PerlInterpreter field whose position depends
+# on sizeof(time_t).  We absorb the former when Perl reports it.  Perl never
+# reports the latter, and we don't attempt to deduce when it's needed.

I don't think this is implemented anywhere now?

+   <para>
+    PostgreSQL for Windows can be built using meson, as described
+    in <xref linkend="install-meson"/>.
+    The native Windows port requires a 32 or 64-bit version of Windows
+    2000 or later. Earlier operating systems do
+    not have sufficient infrastructure (but Cygwin may be used on
+    those).
+   </para>

Is this actually true? I don't think we build on win2k...

+   <para>
+    Native builds of <application>psql</application> don't support command
+    line editing. The <productname>Cygwin</productname> build does support
+    command line editing, so it should be used where psql is needed for
+    interactive use on <productname>Windows</productname>.
+   </para>

FWIW, the last time I tested it, readline worked.

/messages/by-id/20221124023251.k4dnbmxuxmqzq7w3@awork3.anarazel.de

+   <para>
+    PostgreSQL can be built using the Visual C++ compiler suite from Microsoft.
+    These compilers can be either from <productname>Visual Studio</productname>,
+    <productname>Visual Studio Express</productname> or some versions of the
+    <productname>Microsoft Windows SDK</productname>. If you do not already have a
+    <productname>Visual Studio</productname> environment set up, the easiest
+    ways are to use the compilers from
+    <productname>Visual Studio 2022</productname> or those in the
+    <productname>Windows SDK 10</productname>, which are both free downloads
+    from Microsoft.
+   </para>

I think we need a reference to mingw somewhere around here. I don't think
everybody can be expected to just know that they should not have navigated to
"Windows" but "MinGW".

+     <variablelist>
+      <varlistentry>
+       <term><productname>ActiveState Perl</productname></term>
+       <listitem><para>
+        ActiveState Perl is required to run the build generation scripts. MinGW
+        or Cygwin Perl will not work. It must also be present in the PATH.
+        Binaries can be downloaded from
+        <ulink url="https://www.activestate.com"></ulink>
+        (Note: version 5.14 or later is required,
+        the free Standard Distribution is sufficient).
+       </para></listitem>
+      </varlistentry>

Continuing to recommend ActiveState perl seems dubious, but I guess that's
material for another patch.

+      <varlistentry>
+       <term><productname>Bison</productname> and
+        <productname>Flex</productname></term>
+       <listitem>
+       <para>
+        <productname>Bison</productname> and <productname>Flex</productname> are
+        required to build from Git, but not required when building from a release
+        file. Only <productname>Bison</productname> versions 2.3 and later
+        will work. <productname>Flex</productname> must be version 2.5.35 or later.
+       </para>
+
+       <para>
+        Both <productname>Bison</productname> and <productname>Flex</productname>
+        are included in the <productname>msys</productname> tool suite, available
+        from <ulink url="http://www.mingw.org/wiki/MSYS"></ulink> as part of the
+        <productname>MinGW</productname> compiler suite.
+       </para>
+
+       <para>
+        You will need to add the directory containing
+        <filename>flex.exe</filename> and <filename>bison.exe</filename> to the
+        PATH environment variable. In the case of MinGW, the directory is the
+        <filename>\msys\1.0\bin</filename> subdirectory of your MinGW
+        installation directory.
+       </para>

I found it a lot easier to use https://github.com/lexxmark/winflexbison

+      <varlistentry>
+       <term><productname>MIT Kerberos</productname></term>
+       <listitem><para>
+        Required for GSSAPI authentication support. MIT Kerberos can be
+        downloaded from
+        <ulink url="https://web.mit.edu/Kerberos/dist/index.html"></ulink>.
+       </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term><productname>libxml2</productname> and
+        <productname>libxslt</productname></term>
+       <listitem><para>
+        Required for XML support. Binaries can be downloaded from
+        <ulink url="https://zlatkovic.com/pub/libxml"></ulink> or source from
+        <ulink url="http://xmlsoft.org"></ulink>. Note that libxml2 requires iconv,
+        which is available from the same download location.
+       </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term><productname>LZ4</productname></term>
+       <listitem><para>
+        Required for supporting <productname>LZ4</productname> compression.
+        Binaries and source can be downloaded from
+        <ulink url="https://github.com/lz4/lz4/releases"></ulink>.
+       </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term><productname>Zstandard</productname></term>
+       <listitem><para>
+        Required for supporting <productname>Zstandard</productname> compression.
+        Binaries and source can be downloaded from
+        <ulink url="https://github.com/facebook/zstd/releases"></ulink>.
+       </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term><productname>OpenSSL</productname></term>
+       <listitem><para>
+        Required for SSL support. Binaries can be downloaded from
+        <ulink url="https://slproweb.com/products/Win32OpenSSL.html"></ulink>
+        or source from <ulink url="https://www.openssl.org"></ulink>.
+       </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term><productname>ossp-uuid</productname></term>
+       <listitem><para>
+        Required for UUID-OSSP support (contrib only). Source can be
+        downloaded from
+        <ulink url="http://www.ossp.org/pkg/lib/uuid/"></ulink>.
+       </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term><productname>Python</productname></term>
+       <listitem><para>
+        Required for building <application>PL/Python</application>. Binaries can
+        be downloaded from <ulink url="https://www.python.org"></ulink>.
+       </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+       <term><productname>zlib</productname></term>
+       <listitem><para>
+        Required for compression support in <application>pg_dump</application>
+        and <application>pg_restore</application>. Binaries can be downloaded
+        from <ulink url="https://www.zlib.net"></ulink>.
+       </para></listitem>
+      </varlistentry>

Except for openssl, where the link is somewhat valuable, the rest don't really
seem to be specific to windows.

+   <sect3 id="install-windows-full-64-bit">
+    <title>Special Considerations for 64-Bit Windows</title>
+    <para>
+     PostgreSQL will only build for the x64 architecture on 64-bit Windows.
+    </para>
+    <para>
+     Mixing 32- and 64-bit versions in the same build tree is not supported.
+     The build system will automatically detect if it's running in a 32- or
+     64-bit environment, and build PostgreSQL accordingly. For this reason, it
+     is important to start the correct command prompt before building.
+    </para>

Isn't this directly contradicting the earlier

+    The native Windows port requires a 32 or 64-bit version of Windows
+    2000 or later. Earlier operating systems do

?

+    <para>
+     To use a server-side third party library such as <productname>Python</productname> or
+     <productname>OpenSSL</productname>, this library <emphasis>must</emphasis> also be
+     64-bit. There is no support for loading a 32-bit library in a 64-bit
+     server. Several of the third party libraries that PostgreSQL supports may
+     only be available in 32-bit versions, in which case they cannot be used with
+     64-bit PostgreSQL.
+    </para>
+   </sect3>

I.e. cannot be used with postgres at all.

Thank you for working on this!

- Andres