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 <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
