gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Debian and package-framework


From: Thomas Lord
Subject: Re: [Gnu-arch-users] Debian and package-framework
Date: Mon, 08 May 2006 12:18:55 -0700
User-agent: Thunderbird 1.5 (X11/20060313)


On 5/8/06, *Sylvain Beucler* <address@hidden <mailto:address@hidden>> wrote:


    * <troll-mode>
    Can you tell me why package-framework ought to replace autoconf?  Is
    it still maintained? If not, wouldn't it be simpler to switch to
    autoconf?  :)
    </troll-mode/>


Package-framework is weakly maintained because, by economic
forces, I have very little time to work on free software for the
community.   Hopefully that will change someday but, right
now, package-framework is in a kind of stasis.

Package-framework ought to replace autoconf in some circumstances
but not in others. It is not a replacement -- it solves a different problem.

As originally built, autoconf was ideal for bootstrapping a small
core of GNU tools on various platforms.   A good example is
GNU Make.   It would not make any sense at all to try to use
package-framework to build GNU Make because package-framework
*depends* on GNU Make.

Autoconf is not ideal for building GNU software in general.
It is far to bloated and it tries too hard to encourage platform-conditionalized
code.   Only a few programs need to be bootstrapped like GCC or
GNU Make -- most programs don't.

As a result of all the bloat and featuritis, autoconf is too unstable.
Countless times I have tried to build this or that GNU package only
to discover that the configure.in or other autoconf input had a bug
and that to fix it, I would have to find and install yet another historic
version of autoconf.   By contrast, while package-framework
has had some portability bugs over the years, once those are fixed
they are fixed.  It just simply works because it doesn't do very much.
It relies on GNU Make features to organize builds.   It works best in
the presence of portability libraries (like libhackerlab) rather than
with lots of platform-conditional code.

Package-framework is by no means bug free or perfect.  It was
never meant as much more than a proof of concept, to later be
developed into a really clean implementation of its core ideas.
Nevertheless, even the prototype tends to work very well, other
than in the social aspect of offending people who are used to
autoconf.

-t





reply via email to

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