On Fri, 2013-06-14 at 12:16 +0000, Barros Pena, Belen wrote: > Web Hob will have a whole page dedicated to build configuration > information. The page has 2 sections: > > * A summary section that will show you things like target(s), machine, > distro, distro version, build system, target system, etc (for a full list, > see the file attached to bug 4259) > > * A BitBake variables section, that will showŠ well: we don't know: that's > the subject of this email > > In general, the variables section is supposed to show you a table with > variables set in your .conf files. That table would include things like > the variable key, a human-friendly version of that key, the variable > value, the file where is set, an explanation of each variable taken from > the project documentation, if the variable value was changed from the YP > defaults, if a value is overridden by another value set for the same > variable in a different .conf file, etc. I also suggested that all > variables set in any .conf file should be included in that table. > > The development team have raised a few issues with the above: > > 1) This is effectively the output of bitbake -e, and it is a big set of > information. > > 2) We'll need to have build history enabled to gather the information, > with the subsequent impact on performance.
Presumably this is only for the configuration data, not down to the individual recipe level so we can turn off the history before the main parse. That means we shouldn't have much affect on performance. > 3) We'll be exposing variables that should not be edited (for example, > most of the stuff in bitbake.conf). > > 4) We'll need to update documentation.conf in order to provide > human-readable names for variables and short descriptions. > > They suggested we create a "white list" of variables and display key, > value and file information. > > I am not particularly satisfied with this, and the reason is the feedback > gathered from the user base during the high-level design phase. What I > heard was: > > 1) This configuration page was regarded as one of the most useful > > 2) The main advantage came from providing visibility of variables within > the same location, instead of having to go 'hunting' through the different > .conf files > > 3) People asked for the ability to show only variables edited by the user > in order to easily locate the cause of problems > > 4) People asked for the ability to see all places where the same variable > was set, and if one of the values was overridden by another. > > 5) My impression from the user base is that they don't need handholding > (which is what a 'white list' of variables curated by us would effectively > do). What they need is easy and well-structured access to information, so > that they can get a complete picture that helps them understand what's > going on. Just a couple of quotes from the interviews that illustrate this > point: > > "Will you be able to search for any variables set in Bitbake?" > > "What you are showing are the basic ones, but there are loads of them in > the framework and some of them are barely known. Right now we are working > on command line and we have to search the manual" > > Another example is a very recent thread on the mailing list when someone's > problem could be addressed by setting the KBRANCH variable, which they > didn't know existed: > > "I didn't know about the KBRANCH variable. That sure helped (Š) KBRANCH > is documented; I found it in the mega-manual after the fact. It's just a > variable I hadn't used yet so I didn't know to look for it. No amount of > documentation can fix that problem." > > In-depth, structured information can help with this "discoverability" > problem. > > 6) Yes, it might be a lot of information, but Web Hob tables provide > pretty powerful content customisation, search and filtering capabilities > that allow people to find specific content and / or display subsets of > information quite easily. > > Some stuff we could do: > > 1) To manage the performance impact, turn this into a preference that you > can turn on or off. See above, I think we can avoid that. > 2) To manage the amount of information, we could apply a filter to the > table by default, so that when users load it they only see a subset of the > information, but they can see the full content by resetting the filter. > Although, after looking at the output of bitbake -e, if you display only > the key / value pairs it doesn't seem to me that much. I could be totally > wrong though. > > 3) Your suggestions here. Part of the trouble is that to bitbake internally, everything is a key/value pair. We do have some information against the pairs pairs. I'd suggest we don't show tasks/functions/handlers for example which would reduce the output compared to the bitbake -e output. Anther idea might be to limit ourselves to variables which have a [doc] flag? I do agree there are probably too many variables around so we will need to be clever about how we filter the data. Whilst I am nervous about having the option of showing them all, I do understand there is a usecase for it. So my proposal would be to proceed with caution and on the understanding that we're going to have to be very clever with the filtering (and default to something usable/manageable/useful). To start with, I'd hack up some filters on the bitbake -e output (its easy to do that in the bitbake code) and see if the lists of variables you get look reasonable if you remove the tasks/functions, only list the doc flagged ones etc. Cheers, Richard _______________________________________________ webhob mailing list [email protected] https://lists.yoctoproject.org/listinfo/webhob
