Re: Recursive make harmful

[Eric Siegerman]

On Thu, May 31, 2001 at 08:37:07PM +0100, Richard Boulton wrote:
> On Thu, May 31, 2001 at 02:29:37PM -0400, Eric Siegerman wrote:
> > So what *is* harmful about recursive makes (besides the admitted
> > performance penalty)?
> 
> Read "Recursive make considered harmful"
> http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html

OK, this paper convinced me!  (Though I can't avoid the suspicion
that there comes a point past which it doesn't scale -- imagine a
single Makefile for the entire FreeBSD distribution.)  Thanks for
the pointer.


On Fri, Jun 01, 2001 at 03:53:26PM +0200, Alexandre Duret-Lutz wrote:
> >>> "Richard" == Richard Boulton <address@hidden> writes:
>  Richard> With separate Makefile.am's in each directory,
>  Richard> automake should be able to figure the bar/foo out from
>  Richard> the directory paths.  The user shouldn't have to worry
>  Richard> about what the path to the top-level is.

That's sure what I want (he exclaims with the zeal of the newly
converted :-) But...

> Is this really possible?  Makefile.am files may contains rules
> which need to be patched if you move them at another level.
> Somehow, each target should be written in a relocatable way,
> taking care of directory paths.

Well, a simple filename would be "a relocatable way", wouldn't
it?

More seriously, perhaps what's needed is a way for automake to
distinguish between input files that are supposed to be
translated into Makefile(.in)'s -- as has up to now been the case
for *all* of its input Makefile.am's -- and input files which
represent only includeable fragments.  I can think of several
ways for it to distinguish:

 1. a command-line option, e.g. --non-recursive

 2. a different name for the input fragments:
    Makefile.fragment.am or Makefile.include.am or Makefile.af
    (to keep DOS happy) or something

 3. something within a Makefile.am that declares it to represent
    a fragment instead of a full Makefile

One advantage of (1) is that it tells automake right off the bat
what's up.  Automake can then behave differently in whatever ways
are a appropriate for a non-recursive-make situation, rather than
trying to intuit which way to go.  For example, it can:
  - Automatically add "include" directives for all the fragments,
    so I don't have to code them.

  - Or instead, just slurp all the fragments bodily into the main
    Makefile.in, rather than generating an includeable fragment
    file for each one.  This is probably safer, since including
    the translated fragments requires a way to append to a macro,
    which is make-dependent at best.

  - Get the Makefile dependencies right.  If it's slurping
    in fragments, the dependency needs to be:
        ./Makefile.in: foo/bar/Makefile.am
    not:
        foo/bar/Makefile.in: foo/bar/Makefile.am

  - Leave behind those stub Makefile's that somebody mentioned,
    so you can type "make" in a subdirectory

I'm sure there other things it should do differently, that I'm
not thinking of.

One aspect of (1) that could be construed as either a pro or a
con, I suppose, is that it discourages hybrid schemes --
partially recursive and partially non.

--

|  | /\
|-_|/  >   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)