Re: Remove MSVC scripts from the tree

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&dt=2023-10-11%2020%3A21%3A17&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