On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
> On Wed, Dec 11, 2019 at 8:18 AM Trevor Woerner <[email protected]> wrote:
> >
> > Is there a document, or better yet a diagram, showing the order in which
> > various config files, recipes, tasks, etc are parsed?
> >
> > Figuring out the order of the config files is easy enough (bitbake.conf),
> > but
> > trying to figure out when various other parts are processed is just a guess
> > for me right now.
>
> well the easiest way to visualize it is to think about all variables
> being in a large array. Each variable (each row) having a different
> 'value' for each 'column' and each column representing a recipe. When
> bitbake references a variable it is always in the context of a given
> recipe, so you are looking at a specific 'column'. Initially this
> array is filled with default values resulting from the parsing of all
> global .conf files, as you noticed the list of conf files and the
> order is set in bitbake.conf (which itself is hardcoded in bitbake,
> and the first file to parse).
>
> then bitbake will parse each recipe, one by one, and update each
> variable's value in that array (in the relevant column). At the end of
> the parsing, you have all variables which are known.
>
> you can use bitbake -e to print variables value:
>
> bitbake -e | grep ^MESON_BUILDTYPE
>
> it will show you the default value (if it is set) outside the context
> of any recipe.
>
> bitbake -e <bar> | grep ^MESON_BUILDTYPE
>
> will give you the value of this variable as it is set in <bar> recipe
Ooh, I like this already! Your row/column concept is a good mental map of the
process. Your explanation cleared up the "bitbake -e" vs "bitbake -e <bar>"
case for me too!
> The content of the class is parsed when it is inherited. So you need
> to initialize class variables *before* you inherit the class. e.g.
>
> MESA_BUILD_TYPE ?= "release"
> ...
> inherit meson
>
> in your case is very different from
> inherit meson
> ...
> MESA_BUILD_TYPE ?= "release"
>
> > +python do_check_build_type() {
> > + _buildtype = d.getVar('MESA_BUILD_TYPE')
> > + if _buildtype not in ['release', 'debug']:
> > + bb.fatal("unknown build type (%s), please set to either
> > 'release' or 'debug'" % _buildtype)
> > + if _buildtype == 'debug':
> > + d.setVar('MESON_BUILDTYPE', 'debugoptimized')
> > + bb.plain("setting meson build type to debugoptimized")
> > +}
> > +addtask check_build_type before do_configure
> > +
> > EXTRA_OEMESON = " \
> > -Dshared-glapi=true \
> > -Dgallium-opencl=disabled \
Whether I move the above to before or after the "inherit meson..." line makes
no difference. Probably because the variable is being set by a task (which, I
assume, is too late to have any effect, which is a large part of why I wrote
this email: when do these tasks get called with respect to how variable are
being set by all the different ways they're being set?)
> You are
> mixing BUILD_TYPE and BUILDTYPE in your email.. maybe you are mixing
> that in your testing as well? What is set in local.conf will be parsed
> first, so if you set a variable there, it will be 'set' when you parse
> the recipe, so when you use ?= it should be a no-op.
Notice, though, that I'm using two different variables:
1) MESA_BUILD_TYPE: which can be set to "debug" or "release"
2) MESON_BUILDTYPE: which can be set to "plain" or "debugoptimized"
MESA_BUILD_TYPE is how the user tweaks the MESON_BUILDTYPE from the mesa
recipe. Given what you've said above, however, I can see now that (as you say)
setting:
MESON_BUILDTYPE_pn-mesa = ...
in conf/local.conf will do what I want since this variable is recipe-specific
and setting it in one recipe this way won't affect it in others.
I'm sure some will say "there's your solution, do it that way, problem
solved". However, I think "debug/release" are much more natural than
"plain/debugoptimized". I can't change the MESON_BUILDTYPE strings,
they have to be one of those two, so I introduced MESA_BUILD_TYPE as a
level-of-indirection above MESON_BUILDTYPE to allow the user to use the more
natural "debug/release" wording.
So my real question is (and maybe I'm just yak shaving at this point): given
the row/column view of variable setting, how do we factor in the element of
time? For example, *when* do the variables referenced by anonymous python
functions and by tasks get set?
This works (but doesn't allow me the space for nice error checking):
MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug',
'debugoptimized', 'plain', d)}"
and this doesn't:
python do_check_build_type() {
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either
'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
d.setVar('MESON_BUILDTYPE', 'debugoptimized')
bb.plain("setting meson build type to debugoptimized")
}
addtask check_build_type before do_configure
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#47635): https://lists.yoctoproject.org/g/yocto/message/47635
Mute This Topic: https://lists.yoctoproject.org/mt/68144480/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
