Hi David,

> > 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.
> Maybe add a phony target that would build the test programs?

Yes, adding «all: $(check_PROGRAMS)» to Makefile.am seems to do the
trick.  I see Ken's point about not building what's not needed if you're
a plain user, but as a user installing a tar file I always do `make all
check install' anyway and so they'd end up building those few extra C

> > 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'm not sure what that's about.

I loop around `vi', `sed', and `make' and because the latter succeeds I
think my en-masse edits are going OK.  Do the check or distcheck at the
end, because that takes a while, and get told of a syntax error in
test/fakepop.c because earlier makes didn't build it.

> > 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?
> I agree with Lyndon and Ken that it's helpful to have it close by.

That's three of you.  Do none of you use the revision control's grep?  I
understand Lyndon's point about a local script that greps and filters,
and I often have ./g to do that, but with `git grep' I can search
through the working area's files under its control, so I don't see hits
in output files, the --cached staging area, or a particular revision.
Because MH and all its RCS ,v files are current there are many hits on
them, e.g. for strcpy.  Can't you all just have a checkout of the last
git with MH to look at for reference?  :-)

Cheers, Ralph.

Nmh-workers mailing list

Reply via email to