Re: Towards non-recursive makefiles

From: Jason Gunthorpe (jgg@ualberta.ca)
Date: Sun Jan 23 2000 - 18:32:30 EST


On Sun, 23 Jan 2000, Matthew Wilcox wrote:

> If that turns out to be too slow, then I have an alternative proposition.
> Rename the current Makefiles to Makerules then have small Makefiles in
> each directory which include the Makerules. I want to see how slowly
> it goes once the whole tree is converted before deciding on that.

The way I have traditionaly done makefiles like this is to have each sub
dir have it's own standalone makefile, when you do partial builds only
that makefile is run. When you do full builds the top level makefile
includes the sub ones with the right flags and they aggregate all together
:> (or just recursion, depends on size of project)

So far, the best way I have found to do this is to use make fragements
that are kinda similar to procedures for rule generation ie:

# Program for testing methods
PROGRAM=uritest
SLIBS = -lapt-pkg
SOURCE = uri.cc
include $(PROGRAM_H)

The PROGRAM_H include is specially crafted to make exactly the right rules
for the conditions above. I find this works really well and is much more
flexible than relying on pattern rules or trying to build makefiles (like
automake)

When you run just that makefile standalone it gets the proper relative
paths for everything, but when you include from a top level it has the
necessary logic to get absolute paths. I find you want to advoid things
like VPATH because that just slows make's searches down.

If you use the new gnu-make target-specific variables you can do really
nice things within this framework.

Just a thought,
Jason

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:11 EST