RE: how to do recursive "subsystem" make properly?

[Paul Smith]

On Tue, 2009-11-03 at 13:06 -0800, Mark Galeck (CW) wrote:
> >That said, if nothing needs to be remade, the effect of recursive
> make is to simply run make several times - one for each sub-make -
> each of which do nothing more than determine that nothing needs to be
> done.
> 
> No, this is my point (I think).  The top-level make, will not just
> “determine that nothing needs to be done”.  It will run the subdir
> make, that one will indeed determine that nothing needs to be done.
> But then, the top make, will have to remake all the targets, that
> depended on the “subsystem” target – because the subsystem target was
> “remade”.  

This depends on how you do it.  There are multiple options.

One is to have your top-level makefile not build anything itself, but
merely control all the sub-makes.  Then it doesn't matter.  If you
really want the top-level to do something, you can have it recurse to
the same directory and invoke itself with a special rule.

Another is to use the product of the submake as the target instead of
something like "subdir"; for example if a submake builds a library
libfoo.a, then have that be the target and have the command to build
libfoo.a be the "$(MAKE) -C foosrc" or whatever.  The problem here is if
your submakes build >1 target, it gets hairy.

Another is to use order-only prerequisites and make the subdirectories
be order-only prereqs instead of normal prereqs, so that the targets
don't get rebuilt (see the GNU make manual for more info).

Another is to use sentinel files as the targets; some temporary file
that the submake would only touch if it actually made some change but
wouldn't touch if it didn't: if there's a real file, not a .PHONY
target, and its timestamp doesn't change after make runs the rule to
update it, then make will not treat it as having been modified for
up-to-date computations of targets that depend on it.

There are other possibilities as well, I'm sure.