[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recursive make harmful

From: Eric Siegerman
Subject: Re: Recursive make harmful
Date: Fri, 1 Jun 2001 15:04:55 -0400
User-agent: Mutt/1.2.5i

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"

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'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? 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

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'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: or or
    (to keep DOS happy) or something

 3. something within a 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, 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:
        ./ foo/bar/
        foo/bar/ foo/bar/

  - 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)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]