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

[Clifford Beshers <beshers@cs.columbia.edu>]

   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".)

I think that's an excellent point.  Perhaps the design should include
the ability to spit out equivalent shell scripts.  Not trivial, but I
think it could be stylized to be manageable.

Of course, the other option is to push to have guile as universal as
sh, with pre-compiled binaries for all platforms...  But I don't think
that's realistic, as you pointed out.

...


   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.

Using Scheme to construct stylized Scheme code would be the way to go,
I think.  By stylized, I mean a subset with a limited number of
control constructs, data types and functions, where portable Bourne
shell equivalents of each are known.

Expressing a developer's interface to such a complicated system would
be much easier to express in Scheme using higher order functions than
in any other language I know of.

-- 
Clifford Beshers                     Computer Graphics and User Interfaces Lab
beshers@cs.columbia.edu                         Department of Computer Science
http://www.cs.columbia.edu/~beshers                        Columbia University