[yocto] (How) did you script bitbake/set up nightly builds?

[Alan Martinovic]

It seems the call doesn't work correctly with dash (ls -la /bin/sh):

    subprocess.call(". oe/oe-init-build-env; ls", shell = True)
    /bin/sh: 51: .: Can't open root_dir/scripts/oe-buildenv-internal

Specifying bash explicitly works ok:

    subprocess.call(". oe/oe-init-build-env; ls", shell = True,
executable="/bin/bash")

    ### Shell environment set up for builds. ###
    ...
    ...



On Fri, Aug 31, 2018 at 1:47 PM, Burton, Ross <ross.burton at intel.com> wrote:

> On 31 August 2018 at 12:45, Alan Martinovic <alan.martinovic at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180903/73337a44/attachment.html>