On Wed, Jun 25, 2014 at 10:50:47AM -0700, Greg Stark wrote:
> On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > Well, the fact that initdb didn't produce a working configuration and
> > that make installcheck failed to work properly are bad. But, yeah,
> > it's not totally broken.
>
> Yeah it seems to me that these kinds of autoconf and initdb tests
> failing are different from a platform where the spinlock code doesn't
> work. It's actually valuable to have a platform where people routinely
> trigger those configuration values. If they're broken there's not much
> value in carrying them.
Well, I have to ask this question: why should there be any "vax-specific
code"? What facilities beyond what POSIX with the threading extensions
offers on a modern system do you really need? Why?
It seems to me that NetBSD/vax is a very good platform for testing one's
assumptions about whether one's code is truly portable -- because it is
a moderately weird architecture, with some resource constraints, but with
a modern kernel and runtime offering everything you'd get from a software
point of view on any other platform.
Except, of course, for IEEE floating point, because the VAX's floating point
unit simply does not provide that. But if other tests fail on the VAX or
one's source tree is littered with any other kind of VAX-specific code or
special cases for VAX, I would submit that this suggests one's code has
fairly serious architectual or implementation discipline issues.
Thor