Hi,
On 2022-01-23 16:09:01 -0500, Andrew Dunstan wrote:
> Msys is a unix-like environment that is useful to build Postgres. It's
> not intended as a general runtime environment. We therefore don't build
> msys-aware Postgres. We use msys to build standalone Postgres binaries
> that don't need or use any msys runtime. There is nothing in the least
> bit new about this - that's the way it's been since day one of the
> Windows port nearly 20 years ago.
>
> Speaking as someone who (for my sins) regularly deals with problems on
> Windows, I find msys much easier to deal with than VisualStudio,
> probably because it's so much like what I use elsewhere. So I think
> dropping msys support would be a serious mistake.
I agree that msys support is useful (although configure is *so* slow that I
find its usefullness reduced substantially).
> The most common issues we get are around this issue of virtualized paths
> in the TAP tests. If people followed the rule I suggested upthread, 99%
> of those problems would go away. I realize it's annoying - I've been
> caught by it myself on more than one occasion. Maybe there's a way to
> avoid it, but if there is I'm unaware of it. But I don't think it's in
> any way a good reason to drop msys support.
Needing to sprinkle perl2host and MSYS2_ARG_CONV_EXCL over a good number of
tests, getting weird errors when failing, etc IMO isn't a scalable approach,
for a platform that most of use never use.
Can't we solve this in a generic way? E.g. by insisting that the test run with
a native perl and normalizing the few virtual paths we get invoked with
centrally? Making the msys initial setup a bit more cumbersome would IMO be
an OK price to pay for making it maintainable / predictable from other
platforms, as long as we have some decent docs and decent error messages.
Greetings,
Andres Freund