On Nov 19, 2013, at 2:45 PM, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
> On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote:
>> On Nov 19, 2013, at 2:36 PM, Richard Purdie
>> <richard.pur...@linuxfoundation.org> wrote:
>>
>>> On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
>>>
>>>> Well reproducer case is that build from sstate but such that an external
>>>> module needs to be rebuilt
>>>> if external module also comes from sstate then it all is fine. Its only
>>>> when everything is coming from
>>>> sstate except this external module which needs to be rebuilt then you see
>>>> this problem.
>>>>
>>>> now, I see the code in module-base.class
>>>>
>>>> #
>>>> # Ensure the hostprogs are available for module compilation. Modules that
>>>> # inherit this recipe and override do_compile() should be sure to call
>>>> # do_make_scripts() or ensure the scripts are built independently.
>>>> #
>>>> do_make_scripts() {
>>>> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>>>> make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
>>>> -C ${STAGING_KERNEL_DIR} scripts
>>>> }
>>>>
>>>> so it expects that, do_make_scripts is explicitly called by external
>>>> module recipes
>>>>
>>>> and my recipes did override module_do_compile task but not do_compile like
>>>> below
>>>>
>>>> module_do_compile() {
>>>> oe_runmake
>>>> }
>>>>
>>>> so, is comment wrong there should it say module_do_compile instead ?
>>>>
>>>> will it work with sstate always ?
>>>>
>>>> it will be OK to revert it if thats the case.
>>>
>>> Did you inherit module-base or module? I think the wording applies to
>>> module and not module-base. I think the function used to be in module
>>> and was moved along with the comment which is now incorrect.
>>>
>>
>> inherit module
>
> So in that case there is:
>
> addtask make_scripts after do_patch before do_compile
> do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
> do_make_scripts[deptask] = “do_populate_sysroot”
>
yes I see.
> which forces the make_scripts task to run before compile. I don't see
> how that could therefore fail? :/
>
> Do you have a copy of the exact log?
Not anymore, it was sometime ago, the logs are unfortunately recycled.
> I'm wondering if this is another
> variant of the bitbake dependency bug I just tracked down
> (http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118)
>
ah very likely, I think I will try this fix and revert the kernel.bbclass fix
locally and see if I still am
able to reproduce this issue. In any case I think the kernel.bbclass may be
abandoned since I now think it
was a wrong fix although it did fix the problem
> Cheers,
>
> Richard
>
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
