automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal to fork the build-tools projects


From: Tom Lord
Subject: Re: proposal to fork the build-tools projects
Date: Tue, 15 Oct 2002 10:36:37 -0700 (PDT)

       >> Let's (more formally) identify a _small, finite_ set of GNU
       >> packages that should be maintained in such a way that they
       >> can be built in many environments (or for native GNU
       >> systems), even if no other GNU tools are already installed.
       >> Call this set the "bootstrap packages".

       > So you are proposing to trade in end user convenience
       > (package builds on any system "out of the box") for autotools
       > maintainer convenience (maintainers can assume a fixed
       > environment).  

No.

A de facto set of bootstrap packages already exist.  autoconf was
first built for those packages, and it was used to make them
extraordinarilly portable (to all unixen, VMS, and several systems
you've all but forgetten about).

Those packages don't have many external dependencies or dependencies
among themselves.   To avoid adding any new dependencies, the auto*
tools are maintained with some pretty severe constraints that impede
adding features to them in reasonable ways, at a reasonable pace.

Outside of the bootstrap tools, many (most?) packages do have external
dependencies.   Adding a very small number of _new_ dependencies
(e.g. GNU Make) to the list is not harming "end user convenience".

So the trade-off is autotools' maintainer _inconvenience_ for an easier
to extend auto* collection.  (Maintainers give up the inconvenience of
the bootstrap packages least-common denominator and everyone gets 
the auto* tools a little closer to being simpler and more featureful.)


        > In fact, I don't even believe the premise that the Autotools
        > are particularly hard to maintain to the point that it
        > hinders progress.

Perhaps not to simply _maintain_ -- after all, that's what the
bootstrap fork would have to do.

But to _extend_ with new features or simpler approaches: that's where,
for example, depending on GNU Make can make a world of difference.


-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]