All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] kernel: restore scripts in the sysroot
Date: Tue, 19 Nov 2013 22:45:52 +0000	[thread overview]
Message-ID: <1384901152.16887.34.camel@ted> (raw)
In-Reply-To: <B5287BC8-6DCA-44B5-84FC-72E6E271A4F0@gmail.com>

On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote:
> On Nov 19, 2013, at 2:36 PM, Richard Purdie <richard.purdie@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"

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? 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)

Cheers,

Richard



  reply	other threads:[~2013-11-19 22:46 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-08 21:12 [PATCH 0/1] kernel: restore scripts in the sysroot Bruce Ashfield
2013-10-08 21:12 ` [PATCH 1/1] " Bruce Ashfield
2013-11-19 17:37   ` Mike Crowe
2013-11-19 17:37     ` [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene Mike Crowe
2013-11-19 17:37       ` [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst Mike Crowe
2013-11-19 17:41         ` Bruce Ashfield
2013-11-19 17:46           ` Richard Purdie
2013-11-19 17:56             ` Bruce Ashfield
2013-11-19 17:49           ` Mike Crowe
2013-11-19 17:59             ` Phil Blundell
2013-11-19 17:47       ` [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene Bruce Ashfield
2013-11-19 17:46     ` [PATCH 1/1] kernel: restore scripts in the sysroot Phil Blundell
2013-11-19 17:54       ` Bruce Ashfield
2013-11-19 18:17         ` Bruce Ashfield
2013-11-19 22:29           ` Khem Raj
2013-11-19 22:36             ` Richard Purdie
2013-11-19 22:39               ` Khem Raj
2013-11-19 22:45                 ` Richard Purdie [this message]
2013-11-20  2:59                   ` Khem Raj
2013-11-20  4:43                     ` Bruce Ashfield
2013-11-19 22:37             ` Bruce Ashfield
2013-11-19 22:42               ` Richard Purdie
2013-11-19 22:46                 ` Bruce Ashfield
2013-11-19 23:44               ` Phil Blundell
2013-11-19 22:48                 ` Bruce Ashfield
2013-11-19 23:41             ` Phil Blundell
  -- strict thread matches above, loose matches on Subject: below --
2013-10-04  0:02 [PATCH 0/1] kernel: provide " Bruce Ashfield
2013-10-04  0:02 ` [PATCH 1/1] kernel: restore " Bruce Ashfield
2013-10-04  0:58   ` Khem Raj
2013-10-04  0:59     ` Bruce Ashfield
2013-10-04  7:46   ` Richard Purdie
2013-10-04 12:42     ` Bruce Ashfield
2013-10-04 20:23       ` Khem Raj
2013-10-07  5:02     ` Bruce Ashfield
2013-10-07  9:58       ` Richard Purdie
2013-10-07 15:20         ` Bruce Ashfield
2013-10-07 16:18           ` Richard Purdie
2013-10-07 16:20             ` Bruce Ashfield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1384901152.16887.34.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.