This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
Re: Tired of [auto]make.A... guile-based replacement?
- To: Clifford Beshers <beshers@cs.columbia.edu>, tromey@cygnus.com, autoconf@gnu.org, automake@gnu.org, Clifford Beshers <beshers@cs.columbia.edu>
- Subject: Re: Tired of [auto]make.A... guile-based replacement?
- From: Bruce Korb <korb@datadesign.com>
- Date: Fri, 04 Jun 1999 14:01:40 +0000
- Organization: Data Design Systems, Inc.
- References: <87n1yhyz8m.fsf@raven.localnet> <ncjr9ntgjrq.fsf@nytrdc058.eq.gs.com> <199906032000.QAA22779@renoir.cs.columbia.edu> <87zp2hou87.fsf@poledra.coyote.org> <199906032253.PAA18619@arathorn> <199906040233.WAA23712@renoir.cs.columbia.edu>
- Reply-To: ddsinc09@ix.netcom.com
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.
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.
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.