All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Ohly <patrick.ohly@intel.com>
To: Mike Crowe <mac@mcrowe.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v2 3/3] rm_work.bbclass: clean up sooner
Date: Mon, 13 Feb 2017 11:54:32 +0100	[thread overview]
Message-ID: <1486983272.13854.223.camel@intel.com> (raw)
In-Reply-To: <20170210183213.GA10017@mcrowe.com>

On Fri, 2017-02-10 at 18:32 +0000, Mike Crowe wrote:
> On Thursday 09 February 2017 at 17:24:39 +0100, Patrick Ohly wrote:
> > On Wed, 2017-02-08 at 13:48 +0000, Mike Crowe wrote:
> > > On Wednesday 08 February 2017 at 14:04:42 +0100, Patrick Ohly wrote:
> The part I'd missed is the all-important line in source-release-world.bb:
> 
>  do_source_release[depends] += "core-image-sato:do_build"

Okay, that explains it.

IMHO this do_build dependency should trigger do_rm_work. Your "bitbake
-c all_source_releases source-release-world" intentionally includes a
real world build, not just executing the source release tasks. Cleaning
up while building is the goal of rm_work.bbclass. It's arguably a
deficiency in the previous rm_work.bbclass that it wasn't active in your
case.

Now we just need to find a way to combine these without breaking the
extra tasks.

> > It seems unsafe to have tasks that are not properly ordered and just
> > rely on not activating them in the same build, but without understanding
> > the problem better it is too early to look for a solution.
> 
> Thanks for investigating. If you're still having trouble then I have a
> single patch on top of current oe-core master that reproduces it for me
> that I can send.

I can reproduce it.

As you said earlier, adding "before do_rm_work" solves the problem:
addtask source_release before do_rm_work

That's okay, even when rm_work.bbclass does not get inherited. However,
when rm_work.bbclass, a "normal" build like "bitbake menu-cache" ends up
triggering the source_release task:

$ bitbake -g menu-cache
...
$ grep do_rm_work task-depends.dot  | grep do_source_release | grep menu-cache
"menu-cache.do_rm_work" -> "menu-cache.do_source_release"

Is that acceptable for you?

To me it seems like the right solution. Inheriting
release-source.bbclass could be limited to builds which produce
releases, for example in your CI setup, then normal developers will not
be affected.

With that in mind, you could also just do:
addtask source_release before do_build

And then build with:
bitbake world (or your image)

That seems simpler than the construct with do_all_source_releases and
the special source-release-world.bb.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





  reply	other threads:[~2017-02-13 10:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-13 14:52 [PATCH v2 0/3] rm_work enhancements Patrick Ohly
2017-01-13 14:52 ` [PATCH v2 1/3] gcc-source.inc: cleanly disable do_rm_work Patrick Ohly
2017-01-13 14:52 ` [PATCH v2 2/3] rm_work_and_downloads.bbclass: more aggressively minimize disk usage Patrick Ohly
2017-01-13 14:52 ` [PATCH v2 3/3] rm_work.bbclass: clean up sooner Patrick Ohly
2017-02-08 11:50   ` Mike Crowe
2017-02-08 13:04     ` Patrick Ohly
2017-02-08 13:48       ` Mike Crowe
2017-02-09 16:24         ` Patrick Ohly
2017-02-10 18:32           ` Mike Crowe
2017-02-13 10:54             ` Patrick Ohly [this message]
2017-02-13 12:19               ` Mike Crowe
2017-02-13 12:43                 ` Patrick Ohly
2017-02-17 15:21               ` Running task for all recipes required by an image (was Re: [PATCH v2 3/3] rm_work.bbclass: clean up sooner) Mike Crowe
2017-02-17 15:38                 ` Patrick Ohly

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=1486983272.13854.223.camel@intel.com \
    --to=patrick.ohly@intel.com \
    --cc=mac@mcrowe.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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.