> > 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? :-)
Nmh-workers mailing list