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
