Re: just one of a million reasons why autoconf is a worthless piece of shit (2)

[Paul Smith]

Since your last post seemed to be a bit more willing to engage in a
dialog, I'll send this then I'm done.  Some of these points have been
made already but maybe some concrete examples will help. 

You have two misconceptions which are contributing to your frustration,
I think: the first and largest one is that the goal of autotools is to
make the maintainer's life easier.  As has already been stated a few
times, autotools is not about the maintainer.  Autotools is about the
USER.  In fact this is a philosophy that underlies all of GNU, starting
with the GPL itself.  The idea is that packages should automatically
configure themselves for the user.  You probably don't remember, but
back in the day building a new software package was a time-consuming and
frustrating experience of reading various README and INSTALL files,
editing makefiles and header files by hand, etc.  It would usually take
the better part of a day, or longer, and all the knowledge was unique to
each package and had to be relearned every time you wanted to update it.

Now, users just run configure and make.  There are standard and simple
ways for them to do very complex things, and all that knowledge is
applicable across a huge spectrum of free software.  Even packages that
don't use autoconf quite often provide a "configure" script, for
compatibility (and the number one complaint for those packages is that
their configure script doesn't support some particular feature that
autoconf configure scripts do).

Consider the kinds of things that users of any properly autoconfigured
package can and expect to be able to do:

      * cross-compilation
      * installation into alternate directories, either wholesale or on
        a very granular scale
      * easily adding common prefixes or suffixes to installed targets
      * support for all sorts of bizarre platforms, most of which the
        maintainer of the package has never heard of much less has
        access to.

And, they get it all using nothing more than "configure" and "make".

All of this capability, and most especially making it all simple for the
user, comes at a cost, and that cost is complexity in autoconf and extra
work for the maintainer of the package.  But that's OK, because that's
the design philosophy we are committed to.  We don't see complaints from
users about how hard it is to work with autoconfigured packages (quite
the contrary!), and to us that means we're doing a good job achieving
our most important goal.


The second misconception is that you can greatly simplify package
configuration by targeting what you call "the real world", implying that
autoconf spends too much effort on obscure capabilities that no one
really uses.  In fact, autoconf deals with the real "real world", where
people have systems with strange characteristics and they still want to
compile free software for them.  We want to support that, because our
ultimate aim is to promote the use of free software.  The world that
your "simple" solutions work for is an idealized one where everything is
tidy and perfect and no one wants to do anything out of the ordinary.
That world only exists in test environments.


If you release your software with your configuration environment, and it
gets at all popular, I will bet that you will get countless requests to
add support for lots of features and abilities that autoconf packages
already have, along with reports of problems building and/or installing
on machines autoconf already supports.  And by the time you get done
handling all this you will have spent MORE time and effort on it than
you would have if you'd just used autoconf, AND your environment will be
less portable, more brittle, and frustratingly (for your users)
non-standard.

Cheers!

-- 
-----------------------------------------------------------------------------
 Paul D. Smith <address@hidden>                 http://make.mad-scientist.us
 "Please remain calm--I may be mad, but I am a professional."--Mad Scientist