I personally pretty much agree with the larger picture you propose --
but we can separate concerns.
Forking the build tools projects is orthogonal to any particular
direction to take the non-bootstrapping fork.
-t
From: Bruce Korb <[EMAIL PROTECTED]>
Organization: Home
X-Accept-Language: en
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Content-Type: text/plain; charset="us-ascii"
Sender: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:[EMAIL PROTECTED]?subject=help>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/automake>,
<mailto:[EMAIL PROTECTED]?subject=subscribe>
List-Id: Discussion list for automake <automake.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/automake>,
<mailto:[EMAIL PROTECTED]?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/automake/>
Date: Sun, 13 Oct 2002 09:57:23 -0700
X-UIDL: WE)"!V6*!!SKh"!B%X!!
Tom Lord wrote:
>
> * Maintaining the build tools (autoconf etc) is currently too hard.
>
> The maintainers have to struggle to write portable shell code;....
>
> Those constraints really matter to a small number of packages (the
> "bootstrap packages") but could be reasonably relaxed for other
> packages.
I'm not alone?
> Let's then formally identify a _subset_ of the bootstrap packages,
> which are those GNU tools that other (non-bootstrap) GNU packages are
> allowed to depend on for the build process. For example, GNU Make
> would probably be in this subset, as would a GNU shell. Call this set
> the "build environment packages".
To this should be added a "backfill" library.
Programmers will know that ``#include <backfill.h>''
will ensure that all the standard POSIX-isms will be defined
and ``-lbackfill'' will ensure that much of the commonly
omitted functions will be added as well. Get rid of all
that configury testing cruft. It'll just "be there".
