nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Development Questions. check Programs. register.


From: Ken Hornstein
Subject: Re: [Nmh-workers] Development Questions. check Programs. register.
Date: Mon, 17 Oct 2016 13:15:25 -0400

>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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]