Обсуждение: Simplify documentation related to Windows builds

Hi all,

As promised around thread [1] that has moved the docs related to
Windows into a new sub-section for Visual, here is a follow-up to
improve portions of its documentation, for discussion in the next CF.

Some of my notes:
- How much does command line editing work on Windows?  When it came to
VS, I always got the impression that this never worked.  Andres in [2]
mentioned otherwise because meson makes that easier?
- ActiveState perl should not be recommended IMO, as being able to use
a perl binary requires one to *register* into their service for tokens
that can be used to kick perl sessions, last time I checked.  Two
alternatives:
-- MinGW perl binary.
-- strawberry perl (?) and Chocolatey.
-- MSYS
- http://www.mingw.org/ is a dead end.  This could be replaced by
links to https://www.mingw-w64.org/ instead?

At the end, the main issue that I have with this part of the
documentation is the lack of consistency leading to a confusing user
experience in the builds of Windows.  My recent impressions were that
Andrew has picked up Chocolatey in some (all?) of his buildfarm
animals with Strawberry Perl.  I've had a good experience with it,
FWIW, but Andres has also mentioned me a couple of weeks ago while in
Prague that Strawberry could lead to unpredictible results (sorry I
don't remember all the exact details).

Between MSYS2, mingw-w64 and Chocolatey, there are a lot of options
available to users.  So shouldn't we try to recommend only of them,
then align the buildfarm and the CI to use one of them?  Supporting
more than one, at most two, would be OK for me, my end goal would be
to get rid entirely of the list of build dependencies in this "Visual"
section, because that's just a duplicate of what meson lists, except
that meson should do a better job at detecting dependencies than what
the now-dead MSVC scripts did.  If we support two, the CI and the
buildfarm should run them.

I am attaching a patch that's an embryon of work (little time for
hacking as of life these days, still I wanted to get the discussion
started), but let's discuss which direction we should take moving
forward for 17~.

Thanks,

[1]: https://www.postgresql.org/message-id/ZQzp_VMJcerM1Cs_@paquier.xyz
[2]: https://www.postgresql.org/message-id/20231116010703.gtjyepw7jsvyg6qr@awork3.anarazel.de
--
Michael

Hi,

On Sun, 31 Dec 2023 at 09:13, Michael Paquier <michael@paquier.xyz> wrote:
>
> Hi all,
>
> As promised around thread [1] that has moved the docs related to
> Windows into a new sub-section for Visual, here is a follow-up to
> improve portions of its documentation, for discussion in the next CF.
>
> Some of my notes:
> - How much does command line editing work on Windows?  When it came to
> VS, I always got the impression that this never worked.  Andres in [2]
> mentioned otherwise because meson makes that easier?

I do not know that either.

> - ActiveState perl should not be recommended IMO, as being able to use
> a perl binary requires one to *register* into their service for tokens
> that can be used to kick perl sessions, last time I checked.  Two
> alternatives:
> -- MinGW perl binary.
> -- strawberry perl (?) and Chocolatey.
> -- MSYS

I agree. Also, its installation & use steps are complicated IMO. It is
not like install it, add it to PATH and forget.

> - http://www.mingw.org/ is a dead end.  This could be replaced by
> links to https://www.mingw-w64.org/ instead?

Correct.

> At the end, the main issue that I have with this part of the
> documentation is the lack of consistency leading to a confusing user
> experience in the builds of Windows.  My recent impressions were that
> Andrew has picked up Chocolatey in some (all?) of his buildfarm
> animals with Strawberry Perl.  I've had a good experience with it,
> FWIW, but Andres has also mentioned me a couple of weeks ago while in
> Prague that Strawberry could lead to unpredictible results (sorry I
> don't remember all the exact details).

Postgres CI uses Strawberry Perl [1] as well but it is directly
installed from the strawberryperl.com and its version is locked to
'5.26.3.1' for now.

> Between MSYS2, mingw-w64 and Chocolatey, there are a lot of options
> available to users.  So shouldn't we try to recommend only of them,
> then align the buildfarm and the CI to use one of them?  Supporting
> more than one, at most two, would be OK for me, my end goal would be
> to get rid entirely of the list of build dependencies in this "Visual"
> section, because that's just a duplicate of what meson lists, except
> that meson should do a better job at detecting dependencies than what
> the now-dead MSVC scripts did.  If we support two, the CI and the
> buildfarm should run them.

I agree.

> I am attaching a patch that's an embryon of work (little time for
> hacking as of life these days, still I wanted to get the discussion
> started), but let's discuss which direction we should take moving
> forward for 17~.

The current changes look good.

         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.
+        from <ulink url="https://www.msys2.org/"></ulink>.

Since we are changing that part, I think we need to change 'You will
need to add the directory containing flex.exe and bison.exe to the
PATH environment variable. In the case of MinGW, the directory is the
\msys\1.0\bin subdirectory of your MinGW installation directory.'
sentence to its msys2 version. My initial testing showed that the
directory is the '\usr\bin' subdirectory of the msys2 installation
directory in my environment.

[1] https://github.com/anarazel/pg-vm-images/blob/main/scripts/windows_install_perl.ps1

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

On 2024-01-19 Fr 04:38, Nazir Bilal Yavuz wrote:
>
>> At the end, the main issue that I have with this part of the
>> documentation is the lack of consistency leading to a confusing user
>> experience in the builds of Windows.  My recent impressions were that
>> Andrew has picked up Chocolatey in some (all?) of his buildfarm
>> animals with Strawberry Perl.  I've had a good experience with it,
>> FWIW, but Andres has also mentioned me a couple of weeks ago while in
>> Prague that Strawberry could lead to unpredictible results (sorry I
>> don't remember all the exact details).
> Postgres CI uses Strawberry Perl [1] as well but it is directly
> installed from the strawberryperl.com and its version is locked to
> '5.26.3.1' for now.


FYI Strawberry was a bit stuck for a while at 5.32, but they are now up 
to 5.38. See <https://strawberryperl.com/releases.html>


I agree we shouldn't be recommending any particular perl distro, 
especially not ASPerl which now has annoying license issues.


cheers


andrew


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

On Fri, Jan 19, 2024 at 06:11:40AM -0500, Andrew Dunstan wrote:
> FYI Strawberry was a bit stuck for a while at 5.32, but they are now up to
> 5.38. See <https://strawberryperl.com/releases.html>
>
> I agree we shouldn't be recommending any particular perl distro, especially
> not ASPerl which now has annoying license issues.

The more I think about this thread, the more I'd tend to wipe out most
of "windows-requirements" for the sole reason that it is the far-west
regarding the various ways it is possible to get the dependencies we
need for the build and at runtime.  We could keep it minimal with the
set of requirements we are listing under meson in terms of versions:
https://www.postgresql.org/docs/devel/install-requirements.html

Then we could have one sentence recommending one, at most two
facilities used the buildfarm, like https://www.msys2.org/ or
chocolatey as these group basically all the dependencies we need for a
meson build (right?) while linking back to the meson page about the
version requirements.

One issue I have with the meson page listing the requirements is that
we don't directly mention Diff, but that's critical for the tests.

Thoughts?
--
Michael

Hi,

On Tue, 30 Jan 2024 at 11:02, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Jan 19, 2024 at 06:11:40AM -0500, Andrew Dunstan wrote:
> > FYI Strawberry was a bit stuck for a while at 5.32, but they are now up to
> > 5.38. See <https://strawberryperl.com/releases.html>
> >
> > I agree we shouldn't be recommending any particular perl distro, especially
> > not ASPerl which now has annoying license issues.
>
> The more I think about this thread, the more I'd tend to wipe out most
> of "windows-requirements" for the sole reason that it is the far-west
> regarding the various ways it is possible to get the dependencies we
> need for the build and at runtime.  We could keep it minimal with the
> set of requirements we are listing under meson in terms of versions:
> https://www.postgresql.org/docs/devel/install-requirements.html
>
> Then we could have one sentence recommending one, at most two
> facilities used the buildfarm, like https://www.msys2.org/ or
> chocolatey as these group basically all the dependencies we need for a
> meson build (right?) while linking back to the meson page about the
> version requirements.

I tested both msys2 and chocolatey on the fresh Windows containers and
I confirm that Postgres can be built using these. I tested the
dependencies that are required to build and run Postgres. If more
dependencies are required to be checked, I can test again.

As these will be continuously tested by the buildfarm, I agree that
what you suggested looks better.

> One issue I have with the meson page listing the requirements is that
> we don't directly mention Diff, but that's critical for the tests.

I think that is because most distros come with a preinstalled
diffutils package. It is mentioned under the Windows requirements page
[1] since it does not come preinstalled. However, I agree that it
could be good to mention it under the meson page listing the
requirements.

[1] https://www.postgresql.org/docs/devel/installation-platform-notes.html#WINDOWS-REQUIREMENTS

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

On Thu, Feb 08, 2024 at 04:07:36PM +0300, Nazir Bilal Yavuz wrote:
> I tested both msys2 and chocolatey on the fresh Windows containers and
> I confirm that Postgres can be built using these. I tested the
> dependencies that are required to build and run Postgres. If more
> dependencies are required to be checked, I can test again.

Thanks.

> As these will be continuously tested by the buildfarm, I agree that
> what you suggested looks better.

Okay, I have added a sentence at the end of the requirement section,
in a way similar to what we do for GNU.

>> One issue I have with the meson page listing the requirements is that
>> we don't directly mention Diff, but that's critical for the tests.
>
> I think that is because most distros come with a preinstalled
> diffutils package. It is mentioned under the Windows requirements page
> [1] since it does not come preinstalled. However, I agree that it
> could be good to mention it under the meson page listing the
> requirements.

I have looked at that again and finished with the attached to move on
with the cleanup.

Thoughts, comments and/or opinions?
--
Michael

Hi,

On 2023-12-31 15:13:03 +0900, Michael Paquier wrote:
> Some of my notes:
> - How much does command line editing work on Windows?  When it came to
> VS, I always got the impression that this never worked.  Andres in [2]
> mentioned otherwise because meson makes that easier?

Yea, I made it work. I think the only issue was that the build process is a
bit awkward.


> - ActiveState perl should not be recommended IMO, as being able to use
> a perl binary requires one to *register* into their service for tokens
> that can be used to kick perl sessions, last time I checked.

Indeed, it's far gone.


> Two alternatives:
> -- MinGW perl binary.
> -- strawberry perl (?) and Chocolatey.

My experience with strawberry perl were, um, not encouraging.


> Between MSYS2, mingw-w64 and Chocolatey, there are a lot of options
> available to users.  So shouldn't we try to recommend only of them,
> then align the buildfarm and the CI to use one of them?

I think regardless which of these we use, we should provide a commandline
invocation to actually install the necessary stuff, and occasionally test
that, perhaps automatedly.

One issue with most / all of the above is that that they tend to install only
optimized libraries, which can cause issues when building a debug environment.

I've in the past experimented with vcpkg and conan. Both unfortunately, at the
time at least, didn't install necessary binaries for the compression tools,
which makes it harder to test.  I had started to work on adding an option for
the relevant vcpkg packages to install the binaries, but got stuck on some CLA
stuff (cleared up since), after finding that that required some bugfixes in
zstd.

Greetings,

Andres Freund

Hi,

On 2024-02-09 11:53:35 -0800, Andres Freund wrote:
> > Between MSYS2, mingw-w64 and Chocolatey, there are a lot of options
> > available to users.  So shouldn't we try to recommend only of them,
> > then align the buildfarm and the CI to use one of them?
> 
> I think regardless which of these we use, we should provide a commandline
> invocation to actually install the necessary stuff, and occasionally test
> that, perhaps automatedly.
> 
> One issue with most / all of the above is that that they tend to install only
> optimized libraries, which can cause issues when building a debug environment.
> 
> I've in the past experimented with vcpkg and conan. Both unfortunately, at the
> time at least, didn't install necessary binaries for the compression tools,
> which makes it harder to test.  I had started to work on adding an option for
> the relevant vcpkg packages to install the binaries, but got stuck on some CLA
> stuff (cleared up since), after finding that that required some bugfixes in
> zstd.

One thing I forgot: I found chocolatey to be painfully slow to install. And
even at runtime, the wrappers it installs cause build time slowdowns too. And
unnecessary rebuilds with visual studio, because default install paths trigger
some odd msbuild heuristics.

Greetings,

Andres Freund

Hi,

On 2024-02-09 16:22:35 +0900, Michael Paquier wrote:
> diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
> index ed5b285a5e..af77352e6e 100644
> --- a/doc/src/sgml/installation.sgml
> +++ b/doc/src/sgml/installation.sgml
> @@ -193,6 +193,17 @@
>        example, <literal>ICU_CFLAGS=' '</literal>.)
>       </para>
>      </listitem>
> +
> +    <listitem>
> +     <para>
> +      <indexterm>
> +       <primary>Diff</primary>
> +      </indexterm>
> +
> +      <productname>Diff</productname> is required to run the regression
> +      tests. On Windows, it may not be available by default.
> +     </para>
> +    </listitem>
>     </itemizedlist>
>    </para>

It's not installed by default on a bunch of platforms, including in common
linux distros. The same is true for bison, flex etc, so I'm not sure it's
really worth calling this out here.


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

Btw, this is the only dependency that I hadn't been able to test on windows
when I was hacking on the CI stuff last.  I'm not sure it relly still works.




Greetings,

Andres Freund

On Fri, Feb 09, 2024 at 11:56:08AM -0800, Andres Freund wrote:
> One thing I forgot: I found chocolatey to be painfully slow to install. And
> even at runtime, the wrappers it installs cause build time slowdowns too. And
> unnecessary rebuilds with visual studio, because default install paths trigger
> some odd msbuild heuristics.

For a standalone development machine, I've found that OK and found
that rather straight-forward when testing specific patches.  Now
that's just one experience.
--
Michael

On Fri, Feb 09, 2024 at 11:59:21AM -0800, Andres Freund wrote:
> On 2024-02-09 16:22:35 +0900, Michael Paquier wrote:
>> +      <productname>Diff</productname> is required to run the regression
>> +      tests. On Windows, it may not be available by default.
>> +     </para>
>> +    </listitem>
>>     </itemizedlist>
>>    </para>
>
> It's not installed by default on a bunch of platforms, including in common
> linux distros. The same is true for bison, flex etc, so I'm not sure it's
> really worth calling this out here.

Removing the second sentence would be OK, I assume.

>> -      <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>
>
> Btw, this is the only dependency that I hadn't been able to test on windows
> when I was hacking on the CI stuff last.  I'm not sure it relly still works.

Do you think that [1] would help in that?

[1]: https://community.chocolatey.org/packages/mitkerberos
--
Michael

On Tue, Jan 30, 2024 at 3:02 AM Michael Paquier <michael@paquier.xyz> wrote:
> The more I think about this thread, the more I'd tend to wipe out most
> of "windows-requirements" for the sole reason that it is the far-west
> regarding the various ways it is possible to get the dependencies we
> need for the build and at runtime.  We could keep it minimal with the
> set of requirements we are listing under meson in terms of versions:
> https://www.postgresql.org/docs/devel/install-requirements.html

I'm not very knowledgeable about building software about Windows in
general, but on the rare occasions that I've done it, it was MUCH
harder to figure out where to get things like Perl that it is on Linux
or macOS machines. On Linux, your package manager probably knows about
everything you need, and if it doesn't, you can probably fix that by
adding an additional RPM repository to your configuration or using
something like CPAN to find Perl modules that your OS package manager
doesn't have. On macOS, you can install homebrew or macports and then
get most things from there. But on Windows you have to go download
installers individually for everything you need, and there's lots of
installers on the Internet, and not all of them are prepared by
equally friendly people, and not all of them necessarily work for
building PostgreSQL.

So I think that it's pretty darn helpful to have some installation
instructions in the documentation for stuff like this, just like I
think it's useful that in the documentation index we tell people how
to get the doc toolchain working on various platforms. I understand
the concern about seeming to endorse particular Perl distributions or
other software bundles, but I also don't like the idea of telling
people something that boils down to "hey, it's possible to get this to
compile on Windows, and we know some methods that do work, but we're
not going to tell you what they are because we don't want to endorse
anything so ... good luck!". If we know a set of things that work, I
think we should list them in the documentation and just say that we're
not endorsing the use of these particular distributions but just
telling you that we've tested with them. And then I think we should
update that as things change.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Fri, Mar 22, 2024 at 01:34:43PM -0400, Robert Haas wrote:
> I'm not very knowledgeable about building software about Windows in
> general, but on the rare occasions that I've done it, it was MUCH
> harder to figure out where to get things like Perl that it is on Linux
> or macOS machines. On Linux, your package manager probably knows about
> everything you need, and if it doesn't, you can probably fix that by
> adding an additional RPM repository to your configuration or using
> something like CPAN to find Perl modules that your OS package manager
> doesn't have. On macOS, you can install homebrew or macports and then
> get most things from there. But on Windows you have to go download
> installers individually for everything you need, and there's lots of
> installers on the Internet, and not all of them are prepared by
> equally friendly people, and not all of them necessarily work for
> building PostgreSQL.

Yeah.  These days I personally just go through stuff like Chocolatey
or msys2 to get all my dependencies, or even a minimal set of them.  I
suspect that most folks hanging around on pgsql-hackers do that as
well.  Relying on individual MSIs with many dependencies has the large
downside of causing these to become easily outdated.  When using the
build scripts with src/tools/msvc, now gone, I've had a bunch of these
in my environment hosts.

As of the buildfarm, we have currently (All Hail Andrew for
maintaining most of these):
- faiywren, with strawberry perl and msys.  OpenSSL is from a MSI.  It
uses meson.
- drongo, with a 64b version of OpenSSL installed with a MSI.  It uses
meson and chocolatey.
- lorikeet, cygwin, which is an ecosystem of its own.  OpenSSL has
been installed from a MSI, there's a System32 path.
- hamerkop, with meson.  OpenSSL is installed from strawberry, not a
separate MSI.  Python37 points to a custom MSI.

So, yes, you're right that removing completely this list may be too
aggressive for the end-user.  As far as I can see, there are a few
things that stand out:
- Diff is not mentioned in the list of dependencies on the meson page,
and it may not exist by default on Windows.  I think that we should
add it.
- We don't use activeperl anymore in the buildfarm, and recommending
it is not a good idea based on the state of the project.  If we don't
remove the entry, I would switch it to point to msys perl or even
strawberry perl.  Andres has expressed concerns about the strawberry
part, so perhaps mentioning only msys perl would be enough?
- The portion of the docs about command line editing with psql, cygwin
being mentioned as an exception, does not apply AFAIK.
- Mentioning more the packaging options that exist to not have to
install individual MSIs would be a good addition.

> So I think that it's pretty darn helpful to have some installation
> instructions in the documentation for stuff like this, just like I
> think it's useful that in the documentation index we tell people how
> to get the doc toolchain working on various platforms. I understand
> the concern about seeming to endorse particular Perl distributions or
> other software bundles, but I also don't like the idea of telling
> people something that boils down to "hey, it's possible to get this to
> compile on Windows, and we know some methods that do work, but we're
> not going to tell you what they are because we don't want to endorse
> anything so ... good luck!". If we know a set of things that work, I
> think we should list them in the documentation and just say that we're
> not endorsing the use of these particular distributions but just
> telling you that we've tested with them. And then I think we should
> update that as things change.

+  <para>
+   On Windows, you can find packages for build dependencies using
+   <ulink url="https://www.msys2.org/">MSYS2</ulink>
+   or <ulink url="https://chocolatey.org/">Chocolatey</ulink>.
+  </para>

The last patch I've sent has this diff.  Were you thinking about
completing this list with more options and add more command-level
instructions about how to set up these environments in our docs?  We
could just point to anything provided by these projects.  As far as I
can see, MSYS2 and chocolatey are the interesting ones to mention, and
these are used in the buildfarm at some extent.
--
Michael

Hi,

On 2024-04-12 10:27:01 +0900, Michael Paquier wrote:
> Yeah.  These days I personally just go through stuff like Chocolatey
> or msys2 to get all my dependencies, or even a minimal set of them.  I
> suspect that most folks hanging around on pgsql-hackers do that as
> well.

Did that work with openssl for you? Because it didn't for me, when I tried
that for CI.

I didn't find it easy to find a working openssl for msvc, and when I did, it
was one a page that could easily just have been some phishing attempt. Because
of that I don't think we should remove the link to
https://slproweb.com/products/Win32OpenSSL.html


> So, yes, you're right that removing completely this list may be too
> aggressive for the end-user.  As far as I can see, there are a few
> things that stand out:

> - Diff is not mentioned in the list of dependencies on the meson page,
> and it may not exist by default on Windows.  I think that we should
> add it.

That seems quite basic compared to everything else. But also not opposed.

I guess it might be worth checking if diff is present during meson configure,
so it's not just some weird error. I didn't really think about that when
writing the meson stuff, because it's just a hardcoded command in
pg_regress.c, not something that visible to src/tools/msvc, configure or such.


> - We don't use activeperl anymore in the buildfarm, and recommending
> it is not a good idea based on the state of the project.  If we don't
> remove the entry, I would switch it to point to msys perl or even
> strawberry perl.  Andres has expressed concerns about the strawberry
> part, so perhaps mentioning only msys perl would be enough?

I think it's nonobvious enough to install that I think it's worth keeping
something. I tried at some point, and unfortunately the perl from
git-for-windows install doesn't quite work. It needs to be a perl targeting
ucrt (or perhaps some other native target).




> > So I think that it's pretty darn helpful to have some installation
> > instructions in the documentation for stuff like this, just like I
> > think it's useful that in the documentation index we tell people how
> > to get the doc toolchain working on various platforms.


FWIW, here's the mingw install commands to install a suitable environment for
building postgres on windows with mingw, from the automated image generation
for CI:

https://github.com/anarazel/pg-vm-images/blob/main/scripts/windows_install_mingw64.ps1#L21-L22

I wonder if we should maintain something like that list somewhere in the
postgres repo instead...

Greetings,

Andres Freund

On Fri, Apr 12, 2024 at 02:53:58PM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-04-12 10:27:01 +0900, Michael Paquier wrote:
> > Yeah.  These days I personally just go through stuff like Chocolatey
> > or msys2 to get all my dependencies, or even a minimal set of them.  I
> > suspect that most folks hanging around on pgsql-hackers do that as
> > well.
>
> Did that work with openssl for you? Because it didn't for me, when I tried
> that for CI.

Yes, I recall pulling in OpenSSL from Chocolatey the last time I've
tested it.  Perhaps my memories are fuzzy though, it was a couple of
months ago and I don't have the host at hand anymore.

> I didn't find it easy to find a working openssl for msvc, and when I did, it
> was one a page that could easily just have been some phishing attempt. Because
> of that I don't think we should remove the link to
> https://slproweb.com/products/Win32OpenSSL.html

Okay, noted.

>> So, yes, you're right that removing completely this list may be too
>> aggressive for the end-user.  As far as I can see, there are a few
>> things that stand out:
>
>> - Diff is not mentioned in the list of dependencies on the meson page,
>> and it may not exist by default on Windows.  I think that we should
>> add it.
>
> That seems quite basic compared to everything else. But also not opposed.
>
> I guess it might be worth checking if diff is present during meson configure,
> so it's not just some weird error. I didn't really think about that when
> writing the meson stuff, because it's just a hardcoded command in
> pg_regress.c, not something that visible to src/tools/msvc, configure or such.

A meson check would make sense here to catch that earlier.  We do that
for IPC::Run.

>> - We don't use activeperl anymore in the buildfarm, and recommending
>> it is not a good idea based on the state of the project.  If we don't
>> remove the entry, I would switch it to point to msys perl or even
>> strawberry perl.  Andres has expressed concerns about the strawberry
>> part, so perhaps mentioning only msys perl would be enough?
>
> I think it's nonobvious enough to install that I think it's worth keeping
> something. I tried at some point, and unfortunately the perl from
> git-for-windows install doesn't quite work. It needs to be a perl targeting
> ucrt (or perhaps some other native target).

The question would be which one.  Msys perl is used across a few
buildfarm members, and Andrew has some success with it.

>>> So I think that it's pretty darn helpful to have some installation
>>> instructions in the documentation for stuff like this, just like I
>>> think it's useful that in the documentation index we tell people how
>>> to get the doc toolchain working on various platforms.
>
> FWIW, here's the mingw install commands to install a suitable environment for
> building postgres on windows with mingw, from the automated image generation
> for CI:
>
> https://github.com/anarazel/pg-vm-images/blob/main/scripts/windows_install_mingw64.ps1#L21-L22
>
> I wonder if we should maintain something like that list somewhere in the
> postgres repo instead...

+1.  That sounds to me like the doc material we could add in the
Windows build section for meson.
--
Michael

On Thu, Apr 11, 2024 at 9:27 PM Michael Paquier <michael@paquier.xyz> wrote:
> So, yes, you're right that removing completely this list may be too
> aggressive for the end-user.  As far as I can see, there are a few
> things that stand out:
> - Diff is not mentioned in the list of dependencies on the meson page,
> and it may not exist by default on Windows.  I think that we should
> add it.
> - We don't use activeperl anymore in the buildfarm, and recommending
> it is not a good idea based on the state of the project.  If we don't
> remove the entry, I would switch it to point to msys perl or even
> strawberry perl.  Andres has expressed concerns about the strawberry
> part, so perhaps mentioning only msys perl would be enough?
> - The portion of the docs about command line editing with psql, cygwin
> being mentioned as an exception, does not apply AFAIK.
> - Mentioning more the packaging options that exist to not have to
> install individual MSIs would be a good addition.

I think that we need to get a more definitive answer to the question
of whether command-line editing works or not. I have the impression
that it never has. If it's started working, we should establish that
for certain and probably also establish what made it start working; if
it works provided you do X, Y, or Z, we should establish what those
things are.

I'm cool with adding diff to the list of dependencies.

I'd prefer to see us update the other links rather than delete them.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Wed, May 15, 2024 at 11:25:34AM -0400, Robert Haas wrote:
> I think that we need to get a more definitive answer to the question
> of whether command-line editing works or not. I have the impression
> that it never has. If it's started working, we should establish that
> for certain and probably also establish what made it start working; if
> it works provided you do X, Y, or Z, we should establish what those
> things are.

Right.

> I'm cool with adding diff to the list of dependencies.

This makes sense also to me, still the patch is not completely right
because it has been adding diff in the list for build dependencies.
Perhaps this should just be a new list.

> I'd prefer to see us update the other links rather than delete them.

Okay.  I'm not sure where this patch is going, so I am going to
withdraw it for now.  The state of Windows is going to be a topic at
the next pgconf.dev, anyway.
--
Michael