On 1/23/22 15:07, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Maybe we need to have a README in the tree somewhere that tries to >> explain this. Or maybe we should make our build artifacts msys-aware, >> if that's possible, so that this just works. Or maybe supporting msys >> is not worth the trouble. > I've been wondering that last myself. Supporting Windows-native is > already a huge amount of work, which we put up with because there > are a lot of users. If msys is going to add another large chunk of > work, has it got enough users to justify that? > > The recent argument that this behavior isn't user-visible doesn't do > anything to mollify me on that point; it appears to me to be tantamount > to a concession that no real users actually care about msys.
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. 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. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
