[Top][All Lists]

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

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

From: Ralph Corderoy
Subject: [Nmh-workers] Development Questions. check Programs. register.
Date: Mon, 17 Oct 2016 16:45:09 +0100


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'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.

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?

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.

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?

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?

Cheers, Ralph.

reply via email to

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