[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recursive make harmful
Re: Recursive make harmful
Fri, 1 Jun 2001 15:04:55 -0400
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
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
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:
- 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)
Re: Recursive make harmful, Tom Tromey, 2001/06/20