make vs MKDEBUG vs parallel builds

[matthew green <mrg%eterna.com.au@localhost>]

i believe i have found the cause of intermittent failures with MKDEBUG
set and -j builds.

when you set MKDEBUG, we end up with two targets in the list:

	libfoo.so.x.y 
	libfoo.so.x.y.debug

and the latter depends upon the former.  this all seems fine, except
the rule for the second one *recreates* the former:

        (  ${OBJCOPY} --only-keep-debug ${_LIB.so.full} ${_LIB.so.debug} \
        && ${OBJCOPY} --strip-debug -p -R .gnu_debuglink \
            --add-gnu-debuglink=${_LIB.so.debug} ${_LIB.so.full} \

the 2nd objcopy here removes the ${_LIB.so.full} and recreates it without
the debug, etc., info.

this is where the problem occurs.  when a concurrent install sees that
the file is upto date and tries to install it, it has been removed but
not yet recreated, and the install fails.

ie, the debug rule modifies the target of another rule, and make does not
have a way to express this (nor really should.)

if make supported multiple outputs for one rule, it would be easy to
simply fold the .debug creation into the normal rule, but it doesn't.
(this is similar to the yacc creates two files problem.)


the only real solution i can think of for this is to split this into
3 rules:
	.so
	.so.full
	.so.debug.

this has the unfortunate side effect of increasing the build space for
MKDEBUG builds.  on my amd64 system, i measured approx 170MB of
additional files.

can anyone think of a way to avoid this copy?  if not, i think we'll
have to pay the costs for correct builds.

thanks.


.mrg.