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. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
