Re: [PATCH v2 3/3] rm_work.bbclass: clean up sooner

[Patrick Ohly <patrick.ohly@intel.com>]

On Mon, 2017-02-13 at 12:19 +0000, Mike Crowe wrote:
> On Monday 13 February 2017 at 11:54:32 +0100, Patrick Ohly wrote:
> > 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.
> 
> At the moment it is straightforward to build the source release with a
> simple bitbake invocation.
> 
> Your solution would work, but it would be necessary to meddle with
> local.conf or similar in order to generate the source release.

There is conf/auto.conf for that. local.conf can stay unmodified.

Alternatively, you could also introduce an environment variable which
controls whether release-source.bbclass gets inherited. Add that
variable to the BB_ENV_EXTRAWHITE in your local.conf.sample and builds
with or without the class could be as simple as:
RELEASE_SOURCE=1 bitbake ...

> Is there any way we can get our tasks in as predecessors of rm_work only if
> they would have run anyway? Rather like the way make(1) supports order-only
> prerequisites[1]?

No, I don't think there is such a dependency in bitbake, and I'm not
convinced that the usecase justifies the extra complexity.

It might "feel" natural to use the "addtask before" as such a weaker
ordering relationship and the "addtask after" as the stronger "must run
dependency" relationship, but that's just not the current semantic and
changing it probably would break too much.

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