On 13-08-16 22:29, Denys Vlasenko wrote:
> On Fri, Aug 12, 2016 at 8:53 AM, Richard Purdie <[email protected]> wrote:
>> We (as in the Yocto Project/OpenEmbedded) do a lot of builds of busybox
>> One way I did find of breaking the build was:
>>
>> make; rm libbb/appletlib.o include/NUM_APPLETS.h; make
>>
>> which results in:
>>
>> CC      shell/ash.o
>> shell/ash.c:59:25: fatal error: NUM_APPLETS.h: No such file or
>> directory
>>
>> since NUM_APPLETS.h doesn't get regenerated by "make prepare" after its
>> deleted.
> 
> Makefile hell....
> 
> I can reproduce this, yes.
> 
> When I then run
> 
> make --debug=a -p libbb/lineedit.o >LOG
> 
> I find gobs of data in LOG, and grepping for NUM_APPLETS.h
> 
> 
> include/NUM_APPLETS.h: applets/applet_tables
> #  Implicit rule search has not been done.
> #  Modification time never checked.
> #  File has not been updated.
> #  recipe to execute (from 'applets/Kbuild', line 48):
>         $(call cmd,gen_applet_tables)
> ...
> ...
>   Considering target file 'include/NUM_APPLETS.h'.
>    File 'include/NUM_APPLETS.h' does not exist.
>    Looking for an implicit rule for 'include/NUM_APPLETS.h'.
>    No implicit rule found for 'include/NUM_APPLETS.h'.
>    Finished prerequisites of target file 'include/NUM_APPLETS.h'.
>   Must remake target 'include/NUM_APPLETS.h'.
>   Successfully remade target file 'include/NUM_APPLETS.h'.
> 
> 
> Erm... no, you did not "successfully remade target file",
> stupid machine! It does not run anything! while thinking that
> it "successfully remade target file". (I double-checked).

 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?


 As an aside, there may be a second issue: applets/Kbuild.src specifies the same
command for both include/applet_tables.h and include/NUM_APPLETS.h, but that
command will always generate both files. So if the rules for the two files are
launched in parallel, there is another problem. The easiest way to work around
that is to (arbitrarily) let include/NUM_APPLETS.h depend on
include/applet_tables.h with an empty command:

include/NUM_APPLETS.h: include/applet_tables.h ;

It's not entirely accurate, but in practice it works.


 Regards,
 Arnout

> 
> My google-fu turned up nothing.
> Any ideas whats' going on?
> _______________________________________________
> busybox mailing list
> [email protected]
> http://lists.busybox.net/mailman/listinfo/busybox
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to