Re: make vs MKDEBUG vs parallel builds

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Wed, Jun 3, 2015 at 1:07 PM, matthew green <mrg%eterna.com.au@localhost> wrote:
>
> 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.

I definitely prefer correct dependency to hacks to save build space.
If you *really* want to save space, you can do many other things too.
Even in that case, complicating make files (== faking dependency
informations) must not be done, IMO.

> thanks.
>
>
> .mrg.