[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