Subject: Re: Autoconf for toolchain "replacement library"?
To: Todd Vierling <>
From: James Chacon <>
List: tech-toolchain
Date: 11/13/2001 16:53:02
>: 	(2) Autoconf versionitis.
>Right, and this is the one (and only :) concern I have for doing this with
>autoconf not in-tree.
>My take is that if we put the responsibility of maintaining configure{,.in}
>on those who cross-host (and not on all developers as a whole), not having
>autoconf in-tree is OK.  If the "configure" script starts to lag, thenthose
>of us who have an interest in maintaining it will do so.  8-)

Thats ridiculous...So we'd now have sections in the source tree that someone
can't work on without going out and installing various pkgsrc items also?

That completely destroys the idea of a self building/self maintaining tree.
Just because you plan to maintain it right now doesn't make it correct as
far as things go. 

Bad ideas are bad ideas, even in small form. If you want autoconf to help
here (which I completely agree with), then we have to bite the bullet to
pull in the tools to make it go, so regen'ing the file doesn't require one
to "know" what to do. It should be a make-rule that just does what all
the various kernel genfiles type rules do.


>To make sure there isn't versionitis, we could simply document what version
>of autoconf is required; there's even an autoconf rquired version macro to
>do this.
>-- Todd Vierling <>  *  Wasabi & NetBSD:  Run with it.
>-- CDs, Integration, Embedding, Support --