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/