On 05/19/15 04:35, 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.) >
Without knowing that others felt the same way, I've been playing around with something (that is currently very rudimentary) along the same lines: https://github.com/twoerner/layer-repos It was inspired by Otavio's "setup-environment", which Khem and Koen have also started using for their new project to get Angstrom to use a repo manifest. My repo manifest (from above) includes a "setup" script which you can source (if you want to configure a build) or run directly (if you want to get lists of MACHINEs, DISTROs, etc). If sourced, my setup script prompts the user for a machine, an sdk machine, a distro, and the download directory location. These variables are then put into conf/auto.conf, leaving a user's conf/local.conf for true local, user configurations. The prompting occurs using one of select, dialog, or whiptail. Other things that could/should be configured include (in addition to those already discussed): - choice of compiler (gcc, linaro, external) and version - choice of kernel (linux-yocto, ltsi, bsp, etc) - PACKAGE_CLASSES - EXTRA_IMAGE_FEATURES - USER_CLASSES I feel somewhat strongly that the proper way forward is to make repo manifests (or something like it) an integral part of the build process (or, at the very least, making layers more integral to the build!). In a way that's what the whole "meta-poky" (i.e. git clone http://git.yoctoproject.org/git/poky) is doing, isn't it? We're just packaging openembedded-core, meta-yocto-bsp, meta-yocto, meta-hob, etc _manually_ into one repository. Wouldn't it be less work to just switch to using a repo manifest to pull them together instead of endlessly applying patches twice? I'm glad to see lots of work going on in areas like "bitbake-layers" since that sort of thing helps make layers part of the process, instead of a separate step outside the process. One thing that hinders progress is the fact that some layers don't play nicely together. Some BSP layers, for example, assume you wouldn't ever have more than one BSP layer in your build at a time. The same is true of distro layers. Why would anyone ever have more than one distro layer listed in conf/bblayers.conf at a time? Well, if you wanted to give your users the possibility of choose which distro they want to use, then they have to be available during the "lets have the user choose what they want" phase. Then, in order to make things work, a lot of ad-hoc knowledge needs to be built into the setup script so that it can shuffle layers around depending on what the user chooses (i.e. remove all BSP layers except the one the user chooses, remove all distro layers except the one the user chooses, etc). Maybe the proper way forward is to ask the user a bunch of questions and then pull layers together based on their answers? This would require some way of knowing the list of all possible machines, distros, etc. by somehow only fetching very little from the Internet. Is the metadata that drives http://layers.openembedded.org/layerindex/branch/master/layers/ available someplace (preferably as a git clone)? If it were possible to grab that metadata, then perhaps a setup script could use this information to ask the user all the required questions then, once the user choices were known, it could "bitbake-layers layerindex-fetch" the required layers and get the build going (or at least be able to then ask better questions!). > 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.) The configuration changes that are required to build, say, Wayland are DISTRO_FEATURES, so why then don't we have a poky-wayland, poky-fb, or poky-x11 distros in addition to the poky, poky-lsb, poky-tiny, and poky-bleeding distros? -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core