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

[Greg Chicares]

On 2006-5-12 20:08 UTC, 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 read "Recursive Make Considered Harmful" some time ago but
> confess to having forgotten the details of when it is and is not
> a problem.

I think the main thesis of the paper is that if you have one
standalone submakefile in each of several source directories,
which doesn't know what other submakefiles are doing, then it's
impossible for make to manage interdependencies among them.

IOW: make can do the right thing iff it has the complete DAG.

It's not make that's broken. And it's not recursion that's
broken, per se: finding the string '$(MAKE)' in a makefile
doesn't prove that it's problematic.

> 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.

Then it sounds like your single makefile includes the complete
DAG; yet I believe writing a single makefile doesn't guarantee
that you can't have the "harmful" problem....

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

Does $(module_dir) change during a build--say, because of a
$(foreach) somewhere? I think we can create the "harmful"
situation with a single makefile:

# Name of this makefile.
self := $(lastword $(MAKEFILE_LIST))

.PHONY: all
all:
        $(MAKE) -f (self) target0 module_dir=dir0
        $(MAKE) -f (self) target1 module_dir=dir1

If target0 depends on target1, then aren't we building
shards of a fractured DAG?

> Then I only need to define VPATH once and $(SRCDIR) doesn't get
> "hard-coded" into the dependency lists.
> 
> An alternative would be to use target-specific definitions of
> VPATH and add $(module_dir)/ to the subst match string.
>
> Any thoughts on this setup?  I am being overly paranoid concerning
> recursive make?

Why does it seem good to simplify VPATH by moving complexity
elsewhere? Would it be possible to write an all-inclusive vpath
  all_source_directories := srcdir0 srcdir1 srcdir2...
  vpath %.c $(all_source_directories)
  vpath %.h $(all_source_directories)
instead? The only problem I can see is that files in different
source subdirectories might share the same names; but wouldn't
it seem better to avoid that anyway?

Then you could just write, say,

  target0_objects := obj0a.o obj0b.o
  target1_objects := obj1a.o obj1b.o

  target0$(EXEEXT): $(target0_objects)
  target1$(SHREXT): $(target1_objects)

and express any order dependencies separately. What wouldn't
this take care of?