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

[Jan-Simon Möller]

Hi !

Am Mittwoch, 11. Mai 2016, 16:55:10 schrieb Randy Witt:
> 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 have another use-cases:
5) allow fetched layers to be optional (not added to bblayers.conf)
   - we could build several boards based on the same checkout with
     different layer configurations (e.g. add remove a BSP)
6) we should be able to add (modify?!) settings once we add a layer. See idea 
   below ...

Idea and example:
   Lets assume we fetch a set of layers, the bblayers file is then relatively    
   straightforward (the layers we fetched +/- optional). It would be nice to
   e.g. autogenerate a local.conf but also an local.full.conf which would
   expose the (at best with comments) settings/variables of this specific set 
   of layers.
   This creates visibility of the options - we don't have that right now
   unless you digg through bitbake -e .


-- 
--
Jan-Simon Möller
dl9pf at gmx.de