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

[Paul Eggleton]

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:
> 
> 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

-- 

Paul Eggleton
Intel Open Source Technology Centre