I never said I disagreed with using autoconf for this.

I actually tend to agree that this is the easiest way to try and deal with it.

But...I shouldn't have to have pkgsrc installed (and autoconf then) on my
dev box if I change an in-tree tool to use some -current feature and then
need to regen the configure script.

i.e. if we go this way (which sounds fine), then import autoconf into 
gnu/usr.bin so the tools for updating the source tree are available to 
everyone by default.

Just like we use make/awk scripts/etc to generate files for checkin, those
are using core tools to do it. This would just require adding one more thing
to the base (ok comp actually if you think of sets) system.

James

>
>On Tue, 13 Nov 2001, James Chacon wrote:
>
>: >Based on lukem's suggestion, I'm gearing up to put together a configure.in
>: >for src/tools/compat, to allow the build to determine the missing features
>: >of the host system, and thus bring in compatibility routines for things like
>: >[gs]etprogname() automatically.
>: >
>: >Positives:
>: >* less conditionals added as tool features requiring -current are added
>: >* much easier to cross-host on non-NetBSD-current platforms
>: >
>: >Negatives:
>: >* have to run autoconf to regenerate the "configure" script when adding
>: >  a new conditional feature to the toolchain
>:
>: Unless we're planning on adding autoconf to gnu/usr.bin I strongly suggest
>: against this.
>:
>: To build/add to the base system shouldn't require one to install non-supplied
>: tools from the master source tree.
>
>Running autoconf wouldn't be required for building the system, or even
>necessarily for changing the toolchain bits[*].  The point is to catch
>NetBSD-current-isms when cross-building on NetBSD, building from an earlier
>NetBSD revision, and/or building from a non-NetBSD host.
>
>Autoconf would only need to be run to generate a (checked in) "configure"
>script to be run as part of src/tools.  It would produce .h and .mk files
>containing a list of what would be needed from src/compat to make the
>NetBSD-derived host tools compile and run properly on the host.
>
>The goal here is to make the host tools usable easily on any host OS,
>without causing undue maintenance headaches.  The only alternative I can see
>is a boatload of #ifdefs and some OS-specific .h to set the #defines, and
>that seems more painful to me than simply using autoconf as needed.  Do you
>have other suggestions?
>
>===
>
>[*] Autoconf would need to be run when a tool is changed in such a way that
>    it is tied to NetBSD and/or NetBSD-current.
>
>    If the person who made the tool change is not aware of this dependency,
>    someone else who has a host toolchain on a non-NetBSD host would notice
>    the problem (by failure to compile src/tools) and could apply the
>    appropriate changes to configure{,.in}.
>
>    This means that changes can still be made to the tools without running
>    autoconf, and it is essentially the responsibility of toolchain folks
>    and/or people who host on non-NetBSD platforms to keep configure{,.in}
>    up to date with those changes.
>
>-- 
>-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
>-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/
>
>
>
>
>