[Openembedded-architecture] consolidated configs

[Philip Balister]

On 03/21/2016 01:39 PM, Randy Witt wrote:
> On 03/21/2016 12:33 PM, Trevor Woerner wrote:
>> Hi,
>>
>> I'm curious to know what the best procedure is to propose and
>> carry-out a new
>> feature request for OE (or perhaps propose it, discuss, then decide
>> it's not
>> necessary)?
>>
>> I haven't fleshed out all the nuances, but ideally I'd like to be able
>> to give
>> someone one file, they would run bitbake on it, and end up with a
>> duplicate of
>> my build (which generated that configuration file).
>>
>> My use-case is CI builds. On one machine I do work on a build but when
>> I want
>> to transfer that to my CI there's too many manual steps involved
>> (steps that I
>> invariably get wrong). E.g. I don't always remember that in order to
>> fix some
>> issue I had to both tweak local.conf and add another layer, so on my CI
>> machine I tweak local.conf but forget to add the necessary layer. Or
>> I'll add
>> the layer to bblayers.conf but then forget to actually checkout the
>> layer for
>> my CI build. I am familiar with the 'repo' tool, but 'repo' knows nothing
>> about OE, so it's not a complete solution either. 'repo' might form
>> part of
>> the solution, but isn't a solution by itself.
>>
>> Obviously this doesn't help if my build is based on internal layers or
>> private layers and/or commits that only exist on my build machine. But
>> even
>> in this case the metadata that my build would generate would be
>> sufficient for
>> you (or whatever code we add) to recognize that these objects are not
>> available (either by looking at a repository's remote information, or by
>> looking at the hash of the HEAD which isn't found in a fresh
>> checkout/fetch).
>>
>> Apparently others might be interested in this too? Perhaps the toaster
>> people?
> 
> I'm definitely interested and it's on my "todo" list. The idea I've
> mentioned to Paul many times is a "build descriptor" that consists of
> all the items needed to describe a build.

There is the image-buildinfo.bbclass adds this file to the image. It
seems like extending this class might be a good place to start.

root at ettus-e300:~# cat /etc/build
-----------------------
Build Configuration:  |
-----------------------
DISTRO = nodistro
DISTRO_VERSION = nodistro.0
-----------------------
Layer Revisions:      |
-----------------------
meta              =
(detachedfrom4c02a30):4c02a30f084408d0a6a5149937ef74520f8346dc
e100-bsp          =
(detachedfromeed1cc7):eed1cc7bd61aaefc711237f5952faa23f859454d
e300-bsp          =
(detachedfromeed1cc7):eed1cc7bd61aaefc711237f5952faa23f859454d
common            =
(detachedfromeed1cc7):eed1cc7bd61aaefc711237f5952faa23f859454d
meta-xilinx       =
(detachedfromacdc605):acdc605fdeb4eff997fbe47930f263469dec2067
meta-oe           =
(detachedfrom214e180):214e1801d0efc38d3b6142bdc0d8e58ca593e34c
meta-networking   =
(detachedfrom214e180):214e1801d0efc38d3b6142bdc0d8e58ca593e34c
meta-filesystems  =
(detachedfrom214e180):214e1801d0efc38d3b6142bdc0d8e58ca593e34c
meta-python       =
(detachedfrom214e180):214e1801d0efc38d3b6142bdc0d8e58ca593e34c
meta-sdr          =
(detachedfrom7387cfd):7387cfdd157a76f1185be595a2415352ffe67616
meta-fsl-arm      =
(detachedfrom1047156):10471566d2868b07f8ac832b94d5e98a463826ba
meta-fsl-arm-extra =
(detachedfromc0ff75e):c0ff75e85bcbd616362c21e501dc6df187612cf9
meta-ti           =
(detachedfrom0a222c7):0a222c70845d19a2213ac36803361e8531768cca

Philip
> 
> Since the descriptor defines a build, as long as it's defined well, you
> can use cli, gui, etc to generate it. But more importantly there can be
> "plugins" for whatever CI/builder you want.
> 
> So I would expect that I would use a cli consumer, whereas there could
> also be an autobuilder consumer that reads the descriptor and generates
> the appropriate autobuilder config.
> 
> My main desire was to easily be able to use it with the containers I've
> been working on: https://hub.docker.com/r/rewitt/yocto/tags/, so that I
> could easily distribute builds using coreos or something similar.
> 
> The desire I have is to separate the "build descriptor" from the
> generator and the backend used to consume it.
> 
>> I also think this might help people new to OE, as well as help sort
>> out the
>> BSP proliferation issue.
>>
>> For more information please see:
>>     http://lists.openembedded.org/pipermail/openembedded-core/2016-March/118970.html
>>
>>
>> Best regards,
>>     Trevor
>> _______________________________________________
>> Openembedded-architecture mailing list
>> Openembedded-architecture at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>>
> 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>