"Dan Harkless" wrote:
>Okay, I installed ssh-1.2.27 and was able to successfully check out the nmh
>development tree with CVS.
>I successfully configured (one oddment here -- by default the installation
>prefix came out as /usr/local/nmh -- didn't it used to be /usr/local?) and
>tried a 'make', but it failed right at the beginning with:

I think it's always been /usr/local/nmh, (at least since 0.12 or so)
but I typically use --prefix, so it may have changed back and forth in
that time. I'd have to go back through the tar files to find out. In
any case, I didn't change it, so it should be the same as 1.0.

>    cd . && autoheader
>    /bin/sh: autoheader:  not found.
>    make: *** [stamp-h.in] Error 127
>What the heck is 'autoheader'??  Never heard of it.  I did a grep through
>all the nmh files, and the only mentions of it are the call in Makefile[.in] 
>and a note that config.h[.in] was automatically generated with it.

It's part of the autoconf suite that generates config.h.in from
acconfig.h. The reason autoheader is being regenerated is because the
file 'stamp-h.in' is either missing, or older than acconfig.h. In the
cvs archive, this is pretty likely since it doesn't change, and is
typically size 0. If you have autoconf (which it seems you don't),
it'll run autoheader and regenerate config.h.in. If not, just touch
stamp-h.in and it'll run without it. This should not be a problem
with the tar distribution.

>If this is a new required tool, shouldn't it be mentioned in one or more of
>the documentation files?  Is it only required for developers, or for people
>building from the stable tarballs as well?  Is it part of GNU autoconf?  If
>not, where does one get it?

It's only necessary for changing the autoconf parts, which I've been
doing recently. Specifically, I've been trying to eliminate the
sections that require manual editing in config.h after running
configure. It's done using config.guess and AC_CANONICAL_SYSTEM in
the cvs archive right now.  

I'm trying to ease the need for the guessing out as well by cleaning
up the parts of code that rely on it.  So far, 90% of it points into
vmh.c, which is a bit of a mess. Worse, I've never actually seen vmh
running, so I don't know how it should look, other than the
description in the man page. I'd almost say we should just chuck it,
since it hasn't even been part of the build (it's commented out in
the Makefile), but removing it just because it isn't currently used
feels too much like justification for not fixing it.

One other note, if you check out the main cvs archive, and not the
1.0.1 branch, you've got the development version, which is not
necessarily stable. 

-Doug

Reply via email to