Problem: Depending on what one wants to accomplish, finding out all the parameters that can/must be configured, can be a daunting task. Some are described in various configuration files (ex: distro.conf), others are to be found in .bbclass .bb and .bbappend files. It is certainly possible to invoke bitbake -e to get an idea of what is the environment used to build, but that has the downside of treating on the same level "configurable" parameters with others that are meant to be used internally and not altered by the typical user. Proposal: Introduce a formalised way for the author of a recipe to differentiate normal variables from the knobs that a user is supposed to alter. This could include also some contextual comment and an additional switch for bitbake, so that when invoked with this switch, the output provided would be something like: * recipe xxx * parameter Y - contextual help, from the associated recipe - value that will be used (same as what would be reported by "-e") - file which sets the value used - where this value can be modified (in a recipe, cfg file, etc.) * parameter K - ... - ... - ... - ... * recipe zzz [more of the above] Purpose of the feature request: If implemented, this approach would lay down a filtering layer over the information that is currently available from bitbake, greatly improving the user experience for those who need to consume a large set of recipes (ex: for creating a complex disk image).
Have you looked at the PACKAGECONFIG variable? This was an attempt to make it clear exactly which configuration options any given recipe has...
No, I wasn't aware of it :-/ thanks for the pointer. Reading the docs, it seems to come pretty close to what I was advocating, and is already present in many recipes. So it might just be that I didn't read the correct docs/howtos and what is missing is only the additional level of porcelain that i described, where the info is collected and presented in a user-friendly report.
I think some kind of tool to help display this information would be useful so leaving this open for that (we now have the info in the layers web pages but not from bitbake-layers).
We have: $ less scripts/contrib/list-packageconfig-flags.py and we test it so it's likely working: $ rg list-packageconfig-flags.py meta/lib/oeqa/selftest/cases/oescripts.py 145: runCmd('%s/contrib/list-packageconfig-flags.py -h' % self.scripts_dir) 148: results = runCmd('%s/contrib/list-packageconfig-flags.py' % self.scripts_dir) 158: results = runCmd('%s/contrib/list-packageconfig-flags.py -f' % self.scripts_dir) 167: results = runCmd('%s/contrib/list-packageconfig-flags.py -a' % self.scripts_dir) 179: results = runCmd('%s/contrib/list-packageconfig-flags.py -p' % self.scripts_dir)