Great, that's quite clean. Opting for that, thanks Ross. Be Well, Alan
On Fri, Aug 31, 2018 at 1:47 PM, Burton, Ross <ross.bur...@intel.com> wrote: > On 31 August 2018 at 12:45, Alan Martinovic <alan.martino...@senic.com> > wrote: > > Fair enough, I gave an example with a simple workaround. :) > > > > But you do have a point there, if I'm getting you answer right on a > broader > > level. > > Is it something like this? > > > >> Instead of setting the environment only once and running bitbake > multiple > >> times > >> just make the environment sourcing and bitbake execution an atomic > >> operation. > > > > > > So if I wanted to automate i.e.: > > > > . oe-init-build-env mybuild > > bitbake -c cleanall failure_prone_package > > bitbake failure_prone_package > > bitbake foo #image build > > > > It's fine to do it like this: > > > > subprocess.call(". oe-init-build-env mybuild ; bitbake -c cleanall > > failure_prone_package", shell=True) > > subprocess.call(". oe-init-build-env mybuild ; bitbake > > failure_prone_package", shell=True) > > subprocess.call(". oe-init-build-env mybuild ; bitbake foo", shell=True) > > Yes, that's exactly the idiom. The alternative would be to invoke > oe-init-build-env once and then run export, and parse that to > construct an environment to pass to future bitbake calls. That would > work, but would be more complex. > > Ross >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto