Some of the bitbake variables stored in the webhob database have wrong value. Example: B_pn-xz, B_pn-gdb, B_pn-libomxil.
Please provide more info - What is the value that you got ? What is the value that you expected ? Why do you think the value you expected is the correct one ?
Created attachment 1488 [details] wrong value
The value for B_pn-xz stored by WebHob is '/home/brandusa/poky-contrib/build/tmp/work/i586-poky-linux/bblayers/1.0-r0/build' (see the attachment). It is wrong because bitbake displays other path: brandusa@andreea-Vostro-460:~/poky-contrib/build$ bitbake -e core-image-sato | grep ^B_pn-xz B_pn-xz="/home/brandusa/poky-contrib/build/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/build" B_pn-xz-native="/home/brandusa/poky-contrib/build/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/build"
We're not storing the result of "bitbake -e [target]" but the result of "bitbake -e" as per design. The value is the same as "bitbake -e" value.
It is true that we have agreed that the content of the variables table will be based on the output of bitbake -e. Having said that, what we should probably have agreed is that we will show the variable value used during the build. If that happens to be the one provided by bitbake -e <target>, we have made the wrong decision. Paul: do you happen to know why the value of those B variables is different in bitbake -e <target> and bitbake -e? Is this because the variable value might be modified from the value specified for the target, and that 'final' value is what's provided by bitbake -e? Or is it the other way around? Thanks!
There will always be differences between bitbake -e and bitbake -e <target>, if for no other reason than the recipe that provides <target> will set its own values of variables. I think we have discussed this before however. What is shown in the variable list *must* be what is shown by bitbake -e, because that is the global context in which all of the recipes being built are executed, not just the context for the specified target(s) (and if it was multiple targets of course they would each have different environments). So, I agree this is not a bug. The value of showing B_* is extremely limited though especially given their value cannot be practically shown in this context, and I thus hope we aren't listing these with the default filtering.
(In reply to comment #6) > There will always be differences between bitbake -e and bitbake -e <target>, > if for no other reason than the recipe that provides <target> will set its > own values of variables. > > I think we have discussed this before however. What is shown in the variable > list *must* be what is shown by bitbake -e, because that is the global > context in which all of the recipes being built are executed, not just the > context for the specified target(s) (and if it was multiple targets of > course they would each have different environments). This makes sense: thanks. So, I agree this is not > a bug. The value of showing B_* is extremely limited though especially given > their value cannot be practically shown in this context, and I thus hope we > aren't listing these with the default filtering. Right now, there is no default filtering set for this table. Filters are based on the column headings, so we could apply a filter based on: * value (empty vs. set) * configuration file (for example, show only variables set in local.conf) * description (has or has not) Having said that, if we turn configuration.conf into a 'curated set' of variables we believe are useful to show by default, we could turn the 'description' filter into a 'what we think is useful' vs. 'all' kind of thing.
Verified.