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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
