[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.
>

yes, this makes the output pretty clean now. thanks for the fix.

In the meantime I'm curious how your fix solves the issue, as I can't map your
commit message to the change. Sorry that I may need your help here. :-)

It looks that with your fix those 'noexec' setscene tasks which are originally skipped
now still enter the main runqueue logic to get their stamps file generated, and thus
later when normal 'noexec' tasks are checked all dependent tasks have got their
stamp files ready. Is it true?

However I didn't see much difference between task_failoutright and task_skip, which
neither touches the stamp file. Could you shed some light how this impacts the main 
runqueue logic. I search the code, it looks that only when a task is actually scheduled
to run ("exec_task") make_stamp() is invoked...

Last question for the check_stamp_task condition:

+                    if not t2:
+                        bb.msg.debug(2, bb.msg.domain.RunQueue, "Stampfile %s d
                         iscurrent = False
+                    if t1 < t2:
+                        bb.msg.debug(2, bb.msg.domain.RunQueue, "Stampfile %s <
+                        iscurrent = False
+

Under which case a task depended by others may not get its stamp file ready?

Thanks
Kevin