On 05/19/2015 04:35 PM, Paul Eggleton 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: 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.)
Yes, as I said in the comment, it should be got automatically.
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.
We can learn a lot from hob when we do the implementation.
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.
A type declaration mechanism also sounds good, but I'm afraid that it would make a lot of changes embed in the bbclass or conf files, but the build system itself doesn't need these changes, I'm not sure whether it is worth or not, our aim is just make OE easier for newbies. // Robert
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
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
