[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some (trivial) observations on multi-arch builds

From: Johan Bezem
Subject: Re: some (trivial) observations on multi-arch builds
Date: Sat, 13 May 2006 07:51:10 +0200
User-agent: Thunderbird (Windows/20060308)

David Greene wrote:
In my project, there are a number of source directories that contain
the code for various modules.  Some of these modules are program
drivers (i.e. the "main" routines) while others are program-specific
libraries and still others are shared components referenced by two
or more other modules.

Due to the shared component pieces, I've been reluctant to use
recursive make.  Building in parallel is commonplace here and I
don't want to create race conditions between separate recursive
invocations of make for the shared components.

I have never found any mention of it in the manual, but I found I can represent dependencies between 'directories': If I declare my subdirectories as phony targets, with the "$(MAKE) -C" command as one of the commands to be executed for these targets, and then specify dependencies 'as usual':
  dira/ dirb/ dirc/ : dird/
this perfectly orders the recursion, and hasn't presented any challenge for parallel build yet. Works for Solaris (tested with 2.5-2.7), Linux and Cygwin.
Is this a coincidence, or rather a feature?
At least it solved some of my problems ;-)

I read "Recursive Make Considered Harmful" some time ago but
confess to having forgotten the details of when it is and is not
a problem.

For my taste, there were too many arguments in the sense of "people won't do it right, and if you don't do it right it won't work." Which is correct, only my conclusion is not 'not to do it', as Peter Miller recommended (and used one big makefile instead), but to automate most everything that can be done wrong (for instance, automatic dependency generation, among others).

And yes, if you accept that source files have arbitrary dependencies from any file in any subdirectory of any module (main.c being dependent on ../bee/parse.h, in Miller's sample), then the dependencies need to reflect this. But this is more a matter of physical decomposition of modules, not an issue for make, IMHO.

To be on the safe side, rather than using recursive make, I simply
have the top-level Makefile include .mk files from each top-level
subdirectory which in turn may include .mk files to specify rules
for building components in deeper directories.  In effect, I get
one huge Makefile out that contains every single rule and dependency
to build everything.

This seems to be working rather well so far.  The only tricky part
has to do with specifying sources.  Because I don't actually
recurse into deeper source directories, I do this:

  SRCS := $(subst $(SRCDIR)/,,$(wildcard $(SRCDIR/$(module_dir)/*.c))

As long as your structure's depth doesn't increase, it will work. If someone wants to create a new level of submodules, you'll have work to do.

Then I only need to define VPATH once and $(SRCDIR) doesn't get
"hard-coded" into the dependency lists.

I do not see the advantage of that, assuming the dependency lists are generated automatically.

An alternative would be to use target-specific definitions of
VPATH and add $(module_dir)/ to the subst match string.

target-specific? Can you give an example?
If I'm not mistaken, such variables are only available/defined within the target's command script, so defining VPATH as target-specific will not influence the search for sources...

Any thoughts on this setup?  I am being overly paranoid concerning
recursive make?

Well, I've been using make-recursion successfully since approx. 1998, and no more problems than without recursion. And having only two-liner makefiles for the developers to handle certainly helps avoiding problems ;-)

JB Enterprises - Johan Bezem         Tel:   +49 172 5463210
Software Architect - Project Manager Fax:   +49 172 50 5463210
Realtime / Embedded Consultant       Email: address@hidden
Design - Development - Test - QA     Web:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]