RE: Semi-Parallelizing

[EXT-Pennington, Dale K]

> From: David Boyce [mailto:address@hidden 
> Sent: Tuesday, December 16, 2008 12:49 PM
> 
> On Tue, Dec 16, 2008 at 10:37 AM, EXT-Pennington, Dale K 
> <address@hidden> wrote:

> This might be trickier than you think - making the literal 
> bin dirs depend on the literal lib dirs is unlikely to work. 
> You may be able to work out suitable dependencies between the 
> pseudo-targets representing those build units.

Actually the real file does use pseudo-targets, I explicitly left them
out of the example to shorten the message.

> 
> This seems like a rather drastic "solution". If you elaborate 
> on the "ar issues" a better one may show up.
> 

The Gmake manual explicity mentions potential problems if you have to
different processes attempt to modify and archive at the same time.

> 
> For this I think you might be better served by the 
> .NOTPARALLEL special target.
> 

Ah, I missed that one. Definitely works better as its an override at the
local level, rather than depending on an override from the calling
level. If I read the docs correctly, just have .NOTPARALLEL as a target
anywhere in the makefile keeps that makefile from going parallel.

> 
> You're already invoking make recursively; it's a recursive 
> build model. So I don't see anything particularly troubling 
> about this pattern.
> 

Actually, I had been avoiding actually invoking the local make file from
itself. To date it had been upper level make files invoking lower level
make files. I may be a bit more paranoid then most over recursion, and
wanting to make sure that I do not get into an infinite recursion
situation.

> -David Boyce
>