[poky] about 'noexec' message

[Tian, Kevin]

>From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org]
>Sent: Thursday, December 16, 2010 11:19 PM
>
>On Thu, 2010-12-16 at 17:48 +0800, Tian, Kevin wrote:
>> >From: Tian, Kevin
>> >Sent: Thursday, December 16, 2010 4:46 PM
>> >
>> >>From: Gary Thomas [mailto:gary at mlbassoc.com]
>> >>Sent: Thursday, December 16, 2010 12:10 AM
>> >>
>> >>Note to Richard: I'm still seeing a ton of Noexec messages every time I rebuild
>> >>a package in this tree.  I thought I understood you to say they should happen
>> >>at most once?
>> >>
>> >
>> >Yes, RP's previous patch does reduce the Noexec messages a lot. However there
>> >remains one problem. Current stamp file check also calculates the stamp of tasks
>> >depended on. If those stamps are newer or not exist, the check return False to
>> >indicate mismatched stamp.
>> >
>> >In 'noexec' case, some 'noexec' tasks happen to have some dependent tasks
>> >skipped which thus don't generate stamp files. This makes the check always
>> >failed for those 'noexec' tasks and thus you always observe the Noexec messages.
>> >
>> >I have a patch to fix that, and will send out soon. :-)
>> >
>>
>> Though I managed to remove the rest 'noexec' messages by adding below in
>> check_stamp_task():
>>
>> 	if 'noexec' in taskdep and taskname in taskdep['noexec']
>> 		return True
>>
>> I realized there's one potential risk. Though 'noexec' task is not executed at all,
>> it's considered to be a normal task which normally plays the role of the sync
>> points. Ideally if there're changes on stamp file of tasks that this 'noexec' task
>> depends on, we still want to generate a new stamp file for the 'noexec' task.
>> That way other tasks depending on that 'noexec' task will trigger rebuild too.
>>
>> If we always take 'noexec' task away from the comparison, above chain effect
>> disappears.
>>
>> Current comparison condition for stamp files is:
>>
>> 	if not t2 or t1 < t2
>> 		iscurrent = False
>>
>> I'm not sure under which case a stamp file (t2) doesn't exist, and whether it's
>> safe to use:
>> 	if not t2 and not noexec or t2 and t1 < t2:
>> 		iscurrent = False
>>
>> to check stamp file for 'noexec' task.
>>
>> Or alternative is to simply convert bb.note to bb.debug for 'noexec' message. :-)
>
>I've looked at this and realised that scenequeue should not be trying to
>skip noexec tasks as this means the stamps don't get generated. Instead,
>it should just failoutright and let the secondary code in the main
>runqueue deal with them at the correct point in time.
>
>I've pushed this change, lets see if it solves the issues people have
>been seeing. It certainly makes the output from bitbake more readable
>again.
>

Unfortunately I think this causes another problem when using sstate. I got an error
from m4-native when building from scratch (with prebuilt available):

ERROR: install: cannot stat `xxx/tmp/sysroots/i686-linux/usr/share/gnu-config/config.sub

Actually from the log gnu-config.do_populate_sysroot has been accelerated earlier in
setscene stage, with necessary sysroot files installed. However later gnu-config-native
is still considered requiring rebuild, and thus the installed sysroot files are removed again.
The weird thing under this condition is that m4-native thought that do_populate_sysroot
of gnu-config-native has been completed and thus doesn't wait for new build of 
gnu-config-native to complete, which then triggers above error.

I haven't figure out the reason why this commit causes this confliction: sstate package
is installed successfully but the package still requires rebuild. By reverting this change
this error disappears.

Thanks
Kevin