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 <twoer...@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 <twoer...@gmail.com>
> 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
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#47774): https://lists.yoctoproject.org/g/yocto/message/47774
Mute This Topic: https://lists.yoctoproject.org/mt/68144480/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
