Re: slow makefiles are getting even slower

[Eric Siegerman]

On Thu, Aug 15, 2002 at 05:02:40PM +0200, Zdenek Kabelac wrote:
> [...] there are  no  @VARS@ anywhere in the Makefile.am
> (So in this case I think it could be possible to simply skip
> generation of  Makefile.in files in my eyes.)

This would be bad!  The optimization might well be a good idea
(not sure, and others will have better-informed opinions than
mine), but if so, automake's the wrong place for it.

Equivalent, but much cleaner, would be to put the optimization in
autoconf instead; that program could notice that there are no
@VARS@, and write the configure script to simply copy foo.in to
foo (prepending its "generated file" warning, of course).

Advantages:
  - Encapsulation:  it's autoconf, not automake, that knows what
    elements of a given file require configure-time munging (the
    list of such features might grow in the future, to support
    new autoconf functionality); requiring automake to know
    this stuff too would be bad design

  - Decoupling (corollary of encapsulation):
    > Of course this would require better connection between autoconf & automake
    > As the  AC_OUTPUT  would be using Makefile.am directly)

    Putting the optimization into autoconf would obviate the need
    for such a closer connection.

  - Generality:  Autoconf can trivially apply the same
    optimization to all *.in files, but for Automake to do it to
    any but a Makefile.in would be a gross kludge

Disadvantages:
  - I had to CC the autoconf list :-)

> I think it's unacceptable to create something incompatible - I simply 
> cannot force users to install the latest auto* stuff on their machines
> as this would certainly broke the 'building capabilities' of their
> systems

Do you mean end users (people who just want to compile and
install), or fellow developers?  You're right; it's unreasonable
to ask end users to install new versions of autotools just to
build your package.  It seems to be the consensus, though, that
it's perfectly reasonable to require developers to do so.  They,
after all, are presumably knowledgable enough to use --prefix to
install the autotools in a non-standard location, or at least
clever enough to follow instructions to that effect.

If you agree with that assessment, use AM_MAINTAINER_MODE to
cleanly isolate end users from autotools requirements (in theory
anyway; testing it never hurts :-)


<digression relevence_to_main_argument="yes">

> - and as I do prefer that users are using CVS - as making
> releases is too much time consuming - I could not say:  sorry either
> install newest auto* or use old tarballs - I'd be doing nothing
> else then tarballs...

As a package consumer (whether as an end user or as an occasional
developer who makes my own local patches), I for one really
prefer nicely versioned tarballs that I can (a) "cvs import" into
my own repo, and (b) refer to the version number (or build date)
when asking questions or filing bug reports.  The only time
working directly from the project's CVS repo would be convenient
to me is if I were a core developer, with commit privilege; i.e.
if very nearly all of my changes were meant for public
consumption, not just for my own use.

I've reluctantly started working with JMeter from CVS, because
the main developer commits so much useful stuff in a day that
even nightly builds lag seriously.  (I reported a showstopper
(for me) bug; within an hour or two he'd committed a quick fix,
and by that afternoon or the next morning he'd fixed it properly.
Gotta like it!) But working from the main repo is a pain, and
most open-source tools I work with don't change quickly enough to
be worth putting up with it, IMO.

At the very least, do what many projects do:  automatically build
a nightly release -- you can do it from cron.  That way, assuming
AM_MAINTAINER_MODE again, you maintain end users' isolation from
the autotools.

Your core developers will still be working from your CVS repo ...
but then, by the above argument, they'll have installed the
correct autotools versions.

</digression>

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perhaps reach the source.
        - Paul Schneider-Esleben