Re: Plan for single Makefile

[Eric Siegerman]

On Sat, Jul 28, 2001 at 11:58:55AM +1000, Robert Collins wrote:
> What about generating Makefiles for each directory as well - ones that
> are not referenced by the top makefile?

This could be a stub Makefile with proxy targets, like:
        ROOT = ../../..

        all install foo bar baz:
                cd $(ROOT); $(MAKE) $@

So one level of recursion -- but only one -- and you still only
have to parse the main Makefile once (well, once per target), and
you still get the robustness advantages of a single Makefile.

But hang on, I have a better idea...

> 
> or better yet...
> 
> top_src
> \1a
> \1a\2a
> \1a\2b
> 
> in top_src a "single-makefile" that covers all the directories
> in 1a a "single-makefile" that covers 1a and 2a and 2b
> in 2a a standard automake makefile
> in 2b a standard automake makefile.
> 
> Make in 2a will behave the way it does today, just building whats in
> that dir and any dependencies, make in 1a will do a single-makefile
> build of 1a and it's subdirs.

The catch is that "and any dependencies".  One of the big
advantages of a single Makefile is that *all* dependencies get
rebuilt, in the right order, no matter which directory they live
in.

So how about this?  Write a Makefile in each subdirectory, that:
  - includes all the dependency and command info from the
    entire project
  - relocates directory paths to make sense from the directory in
    question
  - customizes the phony targets to include only the ones from
    that directory and below

1a\Makefile would look like:
        ROOT = ..
        include $(ROOT)/Makefile

        all: ...

        install: ...

        # big mess of dependencies and commands; identical in all
        # Makefile's, except for the directory prefixes.

The "all" target would rebuild the same set of things that it
currently does (ie. stuff from \1a\2a, \1a\2b, and \1a, but not
stuff from \1b or \1c).  But because the entire project's info
was available, make would go outside the \1a subtree when
necessary to remake dependencies of those targets -- while still
not insisting on building the *entire* project.

(I started to suggest pulling in the whole-project info via an
include, but just including it bodily in each file is more
straightforward -- and the big reason not to do that,
maintainability, is a nonissue for program-generated Makefiles.
A master Makefile.include would need relocatable directory
prefixes, which would make the whole scheme more intricate and
probably more fragile.

For the output of a program generator like automake, it seems to
me, straightforward, dumb, and repetitive is better than tight,
intricate, and cryptic.  Better to repeat the project's data N
times with minor modifications if it makes the resulting
Makefile.in -- and especially the command log from running make
-- more readable.  Note that the make-time penalty for this
duplication would be zero, since only one of these big Makefiles
would be read on any given run.)

--

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