Re: Tired of make. Anyone interested in a guile-based replacement?

[Ken Raeburn <raeburn@raeburn.org>]

One big problem I have with replacing autoconf is that some of the
proposals require another package at configuration time.  The really
nice thing about autoconf is that it generates a configure script that
can be run by sh, without requiring extra software.  Okay, sh *is*
extra software on Windows, but we're mostly targeting UNIX, where it's
standard.  And yes, there's variation between different
implementations of sh, but autoconf has code for addressing some of
those differences, and more can be added, and AFAIK the variations are
usually minor.  (One big annoying one is the lack of "unset".)

It would kind of suck if configuring emacs on system X in order to
build it required that I have the fooconfig program on my system.  It
would hurt the popularity of emacs, especially if there was anything
non-trivial about fetching, installing and running fooconfig, but even
if there wasn't.

It would be especially bad if fooconfig in turn required (say) perl,
which wouldn't build with the native C compiler, so I need gcc too,
which requires fooconfig to configure it, which needs perl, ....  (No,
perl does *not* come preinstalled on all UNIX systems these days. :-)
Or, to shorten the loop, what if configuring guile to build required
having guile already installed?  (It's a problem with gcc on some
platforms that don't ship with C compilers at all, but I think that's
a special case people are prepared to deal with.  I don't think we
should add more such cases.)

[See also my recent complaints about building guile without having gcc
available.  Or, for that matter, try it without gnu make.]


That said, one of the things I dislike about autoconf (aside from some
of the other points that have been raised) from a design perspective
is that it assumes Bourne shell.  It's got a bunch of macros and
you're supposed to use sh code to glue them together as needed.
There's no provision for generating native scripts for non-UNIX
platforms, or for generating code in any other language for doing the
tests.  (E.g., DOS .bat, VMS .com, Perl, Guile.)  The autoconf code
has no clue about having conditionals around some block of code, so
its requirement analysis (e.g., macro A requires that you use macro B
first) can't take that sort of thing into account.

In other words, I think using sh as *a* language for configuring a
distributed package is good, perhaps necessary, but I'd like to see
others be possible.  (Especially if they can get better performance,
but there are probably performance issues that could be addressed in
the existing autoconf framework too.)

Yes, I know it's difficult at best.

But from a design perspective, having a language specifically for
doing configuration stuff, which could be easily translated to sh or
other simple languages, but which could actually be analyzed for
dependency info, would (I think) be much cleaner than what we've got
now, even if translations to other languages never actually get done.

Of course, it would have to include primitives such as "look for this
string in this file".  And some loop or list processing constructs may
turn pretty ugly when translated to sh.  But as I see it, debugging
the sh code is like debugging the assembly code generated by gcc
... it's not meant to be pretty and easy to understand, it's meant to
me functional and efficient.


just MHO,
Ken