[OE-core] [RFC] Add something like bitbake -cmenuconfig <recipe>?

[Bernhard Reutner-Fischer]

On May 19, 2015 10:35:36 AM GMT+02:00, Paul Eggleton <paul.eggleton at linux.intel.com> wrote:
>On Tuesday 19 May 2015 15:09:31 Robert Yang wrote:
>> Has a uniform backend for configuration sounds like a good idea, here
>are
>> some rough thoughts that we can do in metadata, please feel free to
>give
>> your comments:

Will read the thread but the subject reminds me of http://lists.openembedded.org/pipermail/openembedded-devel/2011-January/074285.html
maybe?

Cheers :)
>> 
>> 1) Add a conf file, bbclass or bb which contains the configable var
>list
>>     for the build, for example, DISTRO, MACHINES, DISTRO_FEATURES,
>>     PACKAGE_CLASSES and so on, we need maintain this file manually,
>we can
>>     discuss what is configurable in the mailing list, it may cost us
>a few
>>     time, but it is really good for OOBE, and would make the new
>user's
>>     life more easier.
>> 
>> 2) Other layer can extend the configable var list easily.
>
>I'd rather we end up with the configuration being defined where the
>variable is 
>actually used - it's tidier and easier to extend.
>
>> 3) Suppose we call the file config-build (.conf, .bbclass or .bb).
>> 
>> 4) The UIs (toaster UI, web HOB, or menuconfig) can invoke the
>contents in
>>     config-build and display them.
>> 
>> 5) The format of config-build can be:
>>     CONFIG_MACHINE[keys] = "machine1, machine2, ..."
>>     # The machines should be got automatically from a function.
>>     CONFIG_MACHINE[doc] = "xxx"
>>     # Re-use the MACHINE[doc] in meta/conf/documentation.conf
>>     [snip]
>
>MACHINE is such that we don't need to define the valid values for it -
>we can 
>simply search for conf/machine/*.conf along BBPATH. (This is what Hob
>does, 
>the mechanism it uses for finding conf files probably still exists.)
> 
>>     CONFIG_IMAGE_FSTYPES[keys] = "typ1, type2, ..."
>>     CONFIG_IMAGE_FSTYPES[doc] = "xxx"
>>     CONFIG_IMAGE_FSTYPES[bbclass] = "image"
>>     # The required bbclass.
>>     [snip]
>
>Similarly here we already have IMAGE_TYPES which defines the valid
>choices for 
>IMAGE_FSTYPES. Possibly not ideal, but it does already exist. On
>bbclasses, 
>surely the usage for a class and any variables it supports ought to be
>defined 
>in the class itself (see bug 6059), then it's easily applicable to any
>class 
>outside of the core.
>
>I think we need to step back a bit and think about how this should be 
>implemented properly. I would urge you to consider that we went through
>a lot 
>of this stuff already quite some time ago with Hob; not that that ended
>up as a 
>perfect codebase by any means, but it would be worth learning from it.
>
>As Chris was suggesting I'd rather we look at setting up a type
>declaration 
>mechanism (possibly at the bitbake level?) and make use of that rather
>than 
>creating something just for this UI where possible.
> 
>> 6) The result will be saved to a file such as local.conf.extend, and
>>     local.conf will include/require it.
>
>We went back-and-forth on this in the Hob timeframe; eventually it was 
>realised that what people really wanted is to have the settings applied
>in 
>local.conf itself rather than some UI-specific conf file. (On the other
>hand, 
>thinking further ahead, we ought to be thinking about distro
>customisation and 
>whether it's really appropriate to put every setting in local.conf as
>opposed 
>to a custom distro config that you select via DISTRO.)
>
>Cheers,
>Paul