Re: Autoconf / Automake for generating Cons scripts

[Eric Siegerman]

Ok, since nobody else is tackling this...

On Tue, Jul 03, 2001 at 05:00:29PM -0400, Rajesh Vaidheeswarran wrote:
> We've received enquiries from a number of cons users regarding the
> ability to generate cons scripts automatically using a "./configure"-type
> facility.

Whatever I say about cons is based on skimming about the first
half of the documentation, so I may well get stuff wrong.

> Pardon me if either of these are not the right groups to pose this
> question to..

They're the right groups.

> Is automake the utility that generates rules for generating make files?

Automake seems to be largely another attempt to solve some of the
same problems with make that the cons people have identified, but
it works as a front-end to make rather than a complete
replacement.  Rather, solving these problems in a make context
leads to a Makefile that's a big ugly mess (BAM :-); automake is
a way to hide that from developers.  You write Makefile.am's, and
automake translates them into the BAMs that are needed to make
"make" do the Right Thing.

(As an illustration, there was recently a thread on the automake
list regarding how to get automake to solve the problem of
recursive Makefile's with their incomplete dependencies etc.)

Another of the things automake is concerned with is writing
Makefile's that contain all the targets mandated by the GNU
standards -- another thing that leads to BAMminess.

> And does autoconf play any part in the process of writing Makefiles to
> directories?

Yes, but in a pretty simple-minded way.  Autoconf is strictly
concerned with figuring out system dependencies, and providing
what it learned in a form useful to the application -- typically
(or only?) in the form of macros that you code in your source
files, Makefile's, etc., and that then get expanded with the
values determined by the autoconf system.

If you're using both automake and autoconf, it looks like this,
in grossly (over)simplified form:
  - you write Makefile.am's
  - you run automake, which translates each Makefile.am into
    a Makefile.in in the same directory (the latter contains the
    aforementioned BAM)
  - you write configure.in, which tells autoconf what
    system-dependent features you need to test for
  - you run autoconf, which translates configure.in into
    configure (the latter is a Bourne-shell script which gets
    included in your distribution)

Time passes; then:
  - the user installing your package runs configure, which tests
    for the system-dependent features, then runs through doing
    macro substitutions on files you mentioned in configure.in.
    Among these files are the Makefile.in's (which, recall, were
    themselves generated by automake)

As regards Makefiles, the kinds of things autoconf/configure are
likely to be interested in are:
  - which stuff you should put in CFLAGS to enable debugging
  - which system libraries the package needs to link with
  - how to invoke the C compiler on this machine (name, options,
    etc.)
  - which system-dependent sources need to be used (e.g.  a
    replacement for snprintf(), which should NOT be compiled if
    the system provides a working snprintf())

But all the work of turning a simple, readable description of the
build process into BAM Makefile's was already done by automake
before you built the distribution.

> If so, is there someone I can work with to see if we generate scripts
> for cons using this tools? If we can, perhaps it would be a useful
> feature to give an option to users to generate makefiles or cons scripts?
> 
> Or if it is so fundamentally different, would it be worth while creating
> a new `autocons' like `automake' to deal with this?

It seems to me (likely shoving foot in mouth :-) that:
  - It may not make sense to write an automake-like frontend to
    cons.  More elegant, if you can get away with it, would be to
    make cons itself support any automake'ish features it's
    lacking.  This can't be done to make for compatibility
    reasons, but perhaps cons is a new enough tool that backward
    compatibility is less of an absolute requirement.

  - On the other hand, it probably DOES make sense to use
    autoconf with cons, and you can probably start doing so in
    small ways without a lot of effort.  Simply identify a few
    system-dependent facts that autoconf can figure out more
    easily than cons can, and figure out what it takes to encode
    the results as macros in the Cons* files.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)