Re: variable and task/function timing


Joel A Cohen
 

As a user, I much prefer having one MESON_BUILD_TYPE variable that I can modify using the pn-operator, even if the acceptable values are a little less pretty. The alternative is a variable that I have to guess that name of and what valid values are per-recipe. Sure it's just MESA_BUILD_TYPE now, but next week is there going to be GLIB_BUILD_TYPE and GTK_BUILD_TYPE too?

Also, if "debugoptimized" is the accepted name from the meson world, I feel it's better to keep it rather than second-guessing them with your own name.

--Aaron

On Wed, Dec 11, 2019 at 10:40 AM Trevor Woerner <twoerner@...> 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@...> wrote:
... 
> 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
-=-=-=-=-=-=-=-=-=-=-=-

Join yocto@lists.yoctoproject.org to automatically receive all group messages.