From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: fairywren is generating bogus BASE_BACKUP commands |
Date: | 2022-01-23 21:31:34 |
Message-ID: | 20220123213134.spwwnjmrl3b4w4fb@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2022-01-23 21:36:24 | Re: row filtering for logical replication |
Previous Message | Andres Freund | 2022-01-23 21:20:05 | Re: Support for NSS as a libpq TLS backend |