openssh unix dev - Jun 2006 - Tracking local changes in CVS

I'm tracking some custom OpenSSH changes (based on 4.3p2) in a local CVS 
repository and have run into a few problems... mainly (I believe) because 
of the .cvsignore files.

Keep in mind the main idea here is to commit the OpenSSH source without 
changes, tag, then add my custom changes and add a new tag.  I can 
probably fix these by making local modes, but I'm just wondering if there 
are specific reasons importing the source without changes doesn't work.

1) .cvsignore includes "configure" and "config.h.in", which
means those
aren't available when I checkout my imported OpenSSH tree.  Is the 
"standard" approach to use the automake stuff to generate these, ie:

    aclocal
    autoconf
    autoheader
    automake

or some combination of those?   When I try to use those as listed above I 
get errors when running automake:

    configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found.
    configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
    configure.ac: that aclocal.m4 is present in the top-level directory,
    configure.ac: and that aclocal.m4 was recently regenerated (using aclocal).
    configure.ac: required file `./missing' not found
    automake: no `Makefile.am' found for any configure output

This is with automake 1.9.5 and autoconf 2.59.

The error appears to be that "AM_INIT_AUTOMAKE" is not in
configure.ac.
Is it supposed to be?

I must admit I had to chuckle at "required file ./missing not
found"... 1)
because "./missing" is required and 2) that "/.missing" was
not found. :-)

2) scard/.cvsignore includes "Ssh.bin" AND scard/Makefile.in has the
rule
for target Ssh.bin commented out.  This means "Ssh.bin" is not checked
out (since it was never checked in) and it doesn't get generated (without 
uncommenting the section in Makefile.in that is).  This causes problems 
when running "make install" even if "Smartcard" support is
disabled.  Is
there some reason the rule for Ssh.bin is commented out?   And should this 
even be run if Smartcard support is disabled?

3) Ok... this last one isn't really a problem with importing into CVS...

If the --with-privsep-path=DIR configure option is used and the DIR 
doesn't exist when "make tests" is run, then "make
tests" will fail.
Shouldn't "make tests" be trying to use a privsep dir inside the
test area
rather then the REAL privsep dir?   Main problem I see with this is if the 
source is built as someone other then root... which means even if "make 
tests" created it's own privsep dir it wouldn't be owned by root.  
In
that case, would it be possible for "make tests" to skip the privsep
tests
and continue rather then failing all tests?

Dan Peterson wrote:
> I'm tracking some custom OpenSSH changes (based on 4.3p2) in a local
CVS
> repository and have run into a few problems... mainly (I believe) because 
> of the .cvsignore files.
It is a little odd that the .cvsignore file is distributed in the
distribution file.  For what you are doing you may want to modify the
.cvsignore file.
> Keep in mind the main idea here is to commit the OpenSSH source without 
> changes, tag, then add my custom changes and add a new tag.  I can 
> probably fix these by making local modes, but I'm just wondering if
there
> are specific reasons importing the source without changes doesn't work.
I am not speaking as an ssh developer (I'm not) but as an ssh user and
as a developer of other software which uses the autotools.
> 1) .cvsignore includes "configure" and "config.h.in",
which means those
> aren't available when I checkout my imported OpenSSH tree.  Is the 
> "standard" approach to use the automake stuff to generate these,
ie:
Generally generated files are not checked into version control.
(There are other opinions on this.  But I disagree with them. :-)
Being generated they are more like object files.  Developers are
expected to have correct versions of the build tools to generate those
files.

But since you are using the distribution image you should be able to
use the files that are distributed without needing to generate your
own.  Unless you are also modifying those files too.  But if not then
you shouldn't need to rebuild them.
>     aclocal
>     autoconf
>     autoheader
>     automake
> 
> or some combination of those?
You are doing too much.  I think only autoconf is needed to generate
the configure script.  In any case openssh does not use automake.
Trying to use that is causing you all kinds of problems.
> The error appears to be that "AM_INIT_AUTOMAKE" is not in
configure.ac.
> Is it supposed to be?
No.  There are no Makefile.am files.  The Makefile.in is supplied.
> I must admit I had to chuckle at "required file ./missing not
found"... 1)
> because "./missing" is required and 2) that "/.missing"
was not found. :-)
You won't need the automake 'missing' file.  (In a project using
automake you would run 'automake --copy' or 'autoreconf
--install' or
similar to have the framework files copied into the project if they
are not there.  The 'missing' script is one of those.)

Bob