|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|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|