On 1/23/22 15:07, Tom Lane wrote:
> Robert Haas <robertmhaas@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