[Openembedded-architecture] consolidated configs
Trevor Woerner
twoerner at gmail.com
Mon Mar 21 19:33:27 UTC 2016
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 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
More information about the Openembedded-architecture
mailing list