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

[Johan Bezem]

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).
(Ref: http://aegis.sourceforge.net/auug97.pdf)

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 ;-)

Johan
--
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:   http://www.bezem.de