On Sun, 2016-08-14 at 01:53 +0200, Arnout Vandecappelle wrote: > The debug output of make is not easy to parse... The -p output comes > _after_ > the -d output, so the rule for NUM_APPLETS.h you have above is not > the one that > is actually used. Indeed, there is a recursive make with > > make -f scripts/Makefile.build obj=applets > > which does NOT include applets/Kbuild, so the rule that is actually > used is: > > include/NUM_APPLETS.h: > # Implicit rule search has been done. > # File does not exist. > # File has been updated. > # Successfully updated. > > > I'm not sufficiently familiar with Kbuild to be able to say how to > make sure > the NUM_APPLETS.h dependency also exists for the sub-make. > > And anyway, this wouldn't solve the parallel build issue it seems, > because > Richard reported multiple executions of "make -f > scripts/Makefile.build > obj=applets". Each of these will independently try to rebuild > NUM_APPLETS.h. > 'make --trace' shows why it is called twice: > > ... > Makefile:372: update target 'applets_dir' due to: scripts_basic > gen_build_files > make -f scripts/Makefile.build obj=applets > ... > Makefile:742: update target 'applets' due to: prepare scripts > make -f scripts/Makefile.build obj=applets > ... > > The second one appears because applets is in core-y - it's actually > the only > thing in core-y. Hm, there is however a dependency chain from applets > to > applets_dir, so they can't actually be called in parallel... > > However, IIRC something changed in the directory handling of make in > recent > years. In my make 4.1 trace, the target is always 'applets', while > the Makefile > is actually working with 'applets/'. Perhaps older make behaves > differently > which results in more calls to applets?
I think this is the real underlying problem which broke our build. I have backported Denys' fix into our builds but I worry there is another bug here which I didn't find a reproducer for as detailed above. Is there a way we could make this issue reproducible so people could look at a fix? I believe the second issue I mentioned is at least addressed now, thanks Denys! Cheers, Richard _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
