Re: Tired of [auto]make.A... guile-based replacement?

[Klaus Schilling <Klaus.Schilling@home.ivm.de>]

Bruce Korb writes:
 > Clifford Beshers wrote:
 > >    FWIW I recently finished configuring a software package with autoconf and
 > >    autoheader (not automake, but I'll probably use that eventually).  It was
 > >    my first time using autoconf/autoheader.  It's not all that bad after you
 > >    get the hang of it; I learned it from the GNU info docs.  I'd *definitely*
 > >    suggest leaving out automake until you've first gotten autoconf and
 > >    autoheader to work.  Or perhaps you already have?
 > > 
 > > I abandoned the whole thing long ago as the spawn of the devil.  :-)
 > > Seriously, though, that's how it made me feel.  It was great at first,
 > > but any time I tried to do something non-standard, I was faced with
 > > random errors, incomplete documentation, bugs, and impenetrable source
 > > code.
 > > 
 > > I really didn't like the philosophy of the whole thing.  It was all ad
 > > hoc names, like a bad AI program.
 > > 
 > > I think having a real programming language would lead to a more open
 > > and comprehensible structure.  Given that, then all of the carefully
 > > collected rules of autoconf and automake could be imported.  Those
 > > rules work just fine, and they should certainly not be discarded
 > > completely, but I think they are too monolithic and need to be
 > > reorganized into a series of manageable transformations.
 > > 
 > > At the very least, they were impenetrable to me as a developer,
 > > causing frustration instead of easing it.
 
Of course as strong Scheme fan I'm all for using guile as unifying 
tool for automake + autoconf + make, as soon as guile's new module- 
and environment system is working. At the current state, it would turn
messy and involve frequent rewrites while guile evolves rapidly.

 > As a developer who went through all of it, I agree completely.
 > And I had a lot of "help".  (Actually, someone else did most all of
 > it!)  The basic concept of constructing configury and makefiles
 > based on build requirements is an excellent idea.  We have
 > now had a prototype done, and it is time to think clearly about
 > an easy to work with design.  Worry first about that, only then
 > worry about conversion tools.

So backward compatibility is no issue? I tried once to write
an m4->scm translator, but it got stuck in a swamp of details.
perl->scm would be a lot harder, even.
 > 
 > I believe the developer's interface should be just a simple list of
 > the targets to build, along with another list of any special rules
 > that may be required for special targets (automake); plus a list of
 > occasionally-non-standard features that are needed (autoconf).  There
 > should be, in general, no need to understand M4, Perl or even Scheme.
 > 
I think all standard stuff should be doable without language knowledge,
by a set of convenient Lisp syntax macros etc ...,
whereas it would be useful to have the possibility to dive into scheme
constructs underneath to achieve non-standard stuff one would not 
usually think of. 

Klaus Schilling