Re: [yocto] variable and task/function timing

["Nicolas Dechesne" <nicolas.dechesne@linaro.org>]

hey Trevor,

On Wed, Dec 11, 2019 at 4:39 PM Trevor Woerner <twoerner@gmail.com> wrote:
>
> On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
> > On Wed, Dec 11, 2019 at 8:18 AM Trevor Woerner <twoerner@gmail.com> 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.

right.. I was confused, I missed a few things in your email (well, it
was really long ;).

>
> 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

I missed the fact that you were using a task.
You can probably call do_check_build_type() when setting
MESON_BUILDTYPE instead of using a task, e.g. something like this:
MESON_BUILDTYPE = "${@do_check_build_type(d.getVar('MESA_BUILD_TYPE'))}"