Re: [avrdude-dev] make distcheck

[Theodore A. Roth]

On Wed, 5 Mar 2003, Brian Dean wrote:

:) Hmmm ... Sorry to make things harder for you Ted, but I had thought
:) that the auto* tools were needed on each system in order to build the
:) source.  That's why I wanted at least the minimum requirements to be
:) what was available on a fairly stock FreeBSD system available be the
:) ports tree.
:)
:) However, I think I now understand that that's not the case - that the
:) auto* tools are only used to build the 'dist', and from there
:) 'configure' does the rest.  If this is indeed the case, then I have no
:) objection at all to using the latest auto* stuff.

That is indeed what is supposed to happen.

:) I just built these on FreeBSD and they seemed to build just fine.  In
:) fact, I just re-bootstrapped my avrdude area with the new tools and it
:) produced a nice clean build.

Good. ;-)

:)
:) However, running a 'make' after ./configure seems to do this:
:)
:)      address@hidden:/avrdude- make
:)      cd . && autoheader
:)      touch ./ac_cfg.h.in
:)      cd . && /bin/sh ./config.status ac_cfg.h
:)      config.status: creating ac_cfg.h
:)      config.status: ac_cfg.h is unchanged
:)      make  all-recursive
:)      Making all in doc
:)      ...
:)
:) Why is that running 'autoheader'?  Am I wrong in my assertion above
:) that once the auto* tools are used to bootstrap, that they are not
:) longer necessary?
:)
:) If autoheader is necessary on the system building avrdude, then we
:) have to stick with whatever is available in the FreeBSD Ports tree.  I
:) can't expect someone to go out and manually install the latest
:) autoheader so that they can build avrdude.  That would be very much
:) contrary to the way the FreeBSD Ports tree is expected to work.

It will still work. But, I just did a test and I think I need to have
configure.ac check for autoconf and if it's not found, then revert the
using the missing script. I'll work on this some more tonight.

:)
:) -Brian
:)
:) P.S. - Can we take 'cvs' off the end of the VERSION string?

We can remove it, but I don't think we should. I put it there to make
sure that there is a clear delineation between an official release and
a snarf from cvs. If you don't have that, then how can you tell which
version someone is using when they say your program doesn't work?

The (undocumented) plan was to revert it just before making an
official dist, commit the official version, tag it and roll the dist
tarball. After the tarball is ok, bump the version, reinstate the cvs
suffix and commit.

It's your call Brian. Remove it if you want.

Ted