[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plan for single Makefile
Re: Plan for single Makefile
Fri, 27 Jul 2001 22:47:32 -0400
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...
> 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
So how about this? Write a Makefile in each subdirectory, that:
- includes all the dependency and command info from the
- relocates directory paths to make sense from the directory in
- customizes the phony targets to include only the ones from
that directory and below
1a\Makefile would look like:
ROOT = ..
# 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)
Re: Plan for single Makefile, Tom Tromey, 2001/07/31
Re: Plan for single Makefile, Alexandre Duret-Lutz, 2001/07/28
- Re: Plan for single Makefile, (continued)
- Re: Plan for single Makefile, Michael Poole, 2001/07/27
- Re: Plan for single Makefile, Lars Hecking, 2001/07/27
- Re: Plan for single Makefile,
Eric Siegerman <=
- Re: Plan for single Makefile, Robert Collins, 2001/07/28
- Re: Plan for single Makefile, Eric Siegerman, 2001/07/30
- Re: Plan for single Makefile, Tom Tromey, 2001/07/31