Seems a bit odd to be mailing nmh-workers with actual "worker"
content... I've noticed things like test/fakepop only get built on a
`make check' because that needs to use them. OTOH, it would be nice to
see compilation succeeds along with everything else in the `all' target.
I've been building all, thinking all's OK, edit, make, ..., and then a
check or distcheck shows up problems from earlier edits. Not sure if my
rusty automake is up to this and wondered what opinions were anyway.
I kind of thought for efficiency's sake we shouldn't build things that
we don't need. It just seems wasteful to me build all of the test suite
programs when they're not used; I guess the thinking there is that
it's fine to make developers do a little more work. We don't do anything
special there with regards to Automake; we're just taking the defaults.
I've taken to passing CFLAGS=-Werror to ./configure so a warning stops
compilation. Otherwise, I was finding, even with my normal `make -s'
that observing just the end of the long output of distcheck wasn't
sufficient. I think the normal way to check for desired silence is
$MAKEFLAGS globbing `*s*' and that would allow those install lines to
maybe disappear, and PASS not to be shown? I'm happy to try and cut the
noise in those cases if there's no objections. `make -s' would ideally
just show any FAIL, the test summary, and distcheck announcement of a
tar file at the end.
I think we're sort of stuck here; the code that generates the test
harness is done by Automake, and there's not really a good way of
redoing that. It may be the parallel test harness is closer to what
you want, but I haven't wanted to go down that route yet because it
would be super-complicated.
Is there a policy not to use nmh's code in the test/*.c helper programs?
None of them use #includes from ./h and do all their own malloc, etc.,
checking. I can see you wouldn't want to borrow a high-level protocol
speaking lump of code if it's meant to be talking to nmh on the other
side since the one error in the one set of source may be hidden if both
sides use it, but sharing utility memory, string, etc., routines
wouldn't seem to have an impact?
Sigh. We don't really have a library of exported routines. I understand
the concept behind unit-tests, but for me at least it was easier to
test the final programs (I didn't write the test suite; I just built
on the hard work of others). Also, there's not always a great division
between library routines and user programs in nmh :-/
C's `register' keyword is sprinkled liberally in some source. I think,
given compilers do a much better job these days, that none are probably
useful, and may even be doing some harm by swaying cc's better decision.
Anyone object to removing them? If they would be useful in some cases
then that's probably not where they were needed back then.
I think all of the remaining register keywords are left over from MH,
and they should go into the dustbin.
There's a lot of duplication of source across files. docs/TODO alludes
to this and I noticed it when checking semi-automatic edits. I'll try
and clean some more of it up though I fear I'm creating ever bigger
problems for others to integrate unpushed changes?
Hm. I think using your own judgement thre is the best you can do.
docs/historical has a whole tree of old MH source. Whilst useful, I
wonder if that can just be tagged and removed so it doesn't clutter `git
grep', etc., output?
Me, I'd like to keep them around; I find it super-convenient and I refer
to it fairly often.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers