[Openembedded-architecture] consolidated configs

[Barros Pena, Belen]

On 21/03/2016 19:33,
"openembedded-architecture-bounces at lists.openembedded.org on behalf of
Trevor Woerner" <openembedded-architecture-bounces at lists.openembedded.org
on behalf of twoerner at gmail.com> 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?

Yes, I think the toaster people are interested.

Cheers

Belén

>
>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/1189
>70.html
>
>Best regards,
>	Trevor
>_______________________________________________
>Openembedded-architecture mailing list
>Openembedded-architecture at lists.openembedded.org
>http://lists.openembedded.org/mailman/listinfo/openembedded-architecture