On May 19, 2015 10:35:36 AM GMT+02:00, Paul Eggleton <paul.eggle...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core