[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Make test-mhical pass with BSD yacc.
From: |
Bob Carragher |
Subject: |
Re: [PATCH] Make test-mhical pass with BSD yacc. |
Date: |
Tue, 22 Sep 2020 02:40:58 -0700 |
Speaking as an NMH leech-user B-), I think the NMH developers and
maintainers should get to specify what the preferred development
and build dependencies should be. (Which, of course, has no
direct bearing on a user that's obtaining pre-built binaries via
a package, like I do via Ubuntu. But it might make development,
or just building, on "limited" systems harder or impossible.)
Making use of a more modern scripting language for testing,
especially if it brings a comprehensive set of testing tools,
seems like it would be a win, if it makes it easier to create
better or more or more rigorous testing. Would we expect a
theoretical new developer to insist on using only older tools?
Bob
On Sun, 20 Sep 2020 19:01:52 -0400 Ken Hornstein <kenh@pobox.com> sez:
> Sigh. This is one of those tough ones. It is nice to have a
> minimum dependency set, but .... I see where you are coming
> from. If we are voting I'd still rather write a simple C
> program to do what we need here, but I recognize that may be a
> minority view.
On Sun, 20 Sep 2020 18:02:58 -0400 David Levine <levinedl@acm.org> sez:
> And it could probably handle at least some of what's in the
> accessory test programs. On the other hand, using an LCD of
> POSIX has advantages of portability and minimizing
> dependencies.
On Sun, 20 Sep 2020 16:01:01 -0500 Eric Gillespie <epg@pretzelnet.org> sez:
> If we're going to look at additional requirements imposed on
> developers, I would suggest that imposition would bring far
> more bang for the buck if it were a proper scripting language
> we can write the tests in. This would not only have made this
> test-mhical problem easier to fix, but also the other one I
> fixed. As Ralph says, we just don't see a way to have derive
> two different timestamp formats from a single source of truth
> with the tools available to us. But with Perl or any of its
> competitors, it would be trivial.