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

[Paul Smith]

Hi Mark; we prefer to use inline posting, not top posting, on the list.
Thanks.

On Tue, 2009-11-03 at 14:16 -0800, Mark Galeck (CW) wrote:
> Oh excellent Paul thank you very much!  I don't want to use the
> product of the submake as a target, because as explained in my first
> message, I think this would necessitate including all the targets on
> which that one depends, essentially all of the sub-makefile.

Not at all.  Suppose you have a makefile that builds libfoo.a in a
subdirectory foosrc.  Then in the upper-level makefile you would have
something like this:

        prog: foosrc/libfoo.a
                ...do something...

        foosrc/libfoo.a: FORCE
                $(MAKE) -C foosrc

        FORCE: ;

In this model, libfoo.a will always be considered out of date (because
of the FORCE prerequisite--just be sure you don't create a file "FORCE"
in your directory), so the command to build it will be invoked.  The
command is the submake.

If the submake actually updates libfoo.a, then "prog" will be rebuilt.
If the submake does not change libfoo.a, then "prog" will not be
considered out of date.

As I said, the problem here is that if "foosrc" builds more than one
target you have issues; you don't want both targets to do this or it
will run the make twice (!)

> But all the other suggestions I really like, especially the
> sentinel.  

Actually the sentinel is, IMO, an annoying implementation.  Managing all
those sentinel files is a PITA.  If you're happy to require GNU make,
I'd probably suggest going with order-only prerequisites (or else going
all the way to non-recursive builds) as the most robust solution.

> (and with the question I had asked a few days ago, that of
> interrupting make not working, to which there were no replys, I assume
> this means "that is the way it is, make does the best possible effort
> to remove the target".  So my workaround, was when building the
> targets, to use a temporary name, and then as the last operation,
> rename it to the correct target name.  )

The problem is your issue, as best as I recall, is Windows-specific.
Most of the people reading this list are using make on POSIX systems,
and ^C on POSIX systems does the right thing (at least in the tests I've
conducted).  You might have more luck asking Windows-specific questions
on the address@hidden mailing list instead: Windows-knowledgeable
folks tend to hang out there.