[Openembedded-architecture] bblayers.conf - Past, Present and Future?

Paul Eggleton paul.eggleton at linux.intel.com
Fri May 13 04:09:15 UTC 2016


On Wed, 11 May 2016 16:55:10 Randy Witt wrote:
> On 05/11/2016 02:57 PM, Mark Hatle wrote:
> > On 5/11/16 4:47 PM, Philip Balister wrote:
> >> Richard, thanks for kicking this off.
> >> 
> >> I've read the other replies in the thread and see there is a very
> >> diverse set of solutions to this problem.
> >> 
> >> Before we worry about solutions, we should figure out what we have in
> >> common. My mind is coming back to an earlier thread (maybe started by
> >> Trevor) about how we describe a build. Does this seem like a good place
> >> to start?
> > 
> > I think that is a good start.
> > 
> > From what I've read.  I'd suggest:
> > 
> > 1) Fetching of layers (initial and update)
> > 2) Identifying the characteristics of the fetch (commit, branch, etc)
> > 3) Setting up the bblayers.conf file
> > 4) Setting up the local.conf file
> > 
> > (I know that is a bit simplistic, but I think captures the high level
> > view.)
>
> This is why I created bug
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9588. If we can figure out
> what constitutes a "build" then we can come up with a reference consumer
> which is bug, https://bugzilla.yoctoproject.org/show_bug.cgi?id=9589.
> 
> I mention this because adding information to the bug would really be
> helpful.

To expand in the direction Randy is proposing on the bug, if you are to 
consider the problem of Toaster executing a build on another machine, use 
within CI infrastructure, or conveniently running a build within a container, 
there are a couple of other things you might want this to specify as well:

1) What tasks/targets you want to execute (i.e. what you might specify on the 
bitbake command line)

2) What to do with the artifacts produced at the end, if anything - since the 
context in which the build is executing might disappear shortly after the 
build finishes.

If you start to consider these types of things it makes the argument to use a 
format that's not simply the existing config files a bit more compelling.

You might argue that we shouldn't try to solve all of these problems with the 
same solution, and that might well be true. However I think we should 
definitely consider all of the problems we do want to solve up front and then 
we can get a better idea of what the solution(s) might look like.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the Openembedded-architecture mailing list