>
>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.

James

>
>What do y'all think of this?  Note that the "configure" script would only be
>run as part of src/tools, of course -- if HAVE_CONFIG_H is not defined (as
>would be the case in src/usr.bin/*), each respective tool will assume an
>appropriately versioned NetBSD host.
>
>-- 
>-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
>-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/
>
>
>
>
>