* variable and task/function timing
@ 2019-12-11 7:18 Trevor Woerner
2019-12-11 10:06 ` [yocto] " Nicolas Dechesne
0 siblings, 1 reply; 10+ messages in thread
From: Trevor Woerner @ 2019-12-11 7:18 UTC (permalink / raw)
To: yocto
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.
Conceptually this is what I want to do:
Currently the meson build system (class) is hard-coded to always produce
a buildtype of "plain", which are (basically) production builds. But
there are other buildtypes that can be specified; such as
"debugoptimized". I want a recipe to be able to influence the meson
buildtype, and I want the user to be able to tweak this parameter from
their conf/local.conf.
Here's what I want to do:
diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index dc8c28963c..e1a13bbbf7 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -12,8 +12,9 @@ MESON_SOURCEPATH = "${S}"
def noprefix(var, d):
return d.getVar(var).replace(d.getVar('prefix') + '/', '', 1)
+MESON_BUILDTYPE ?= "plain"
MESONOPTS = " --prefix ${prefix} \
- --buildtype plain \
+ --buildtype ${MESON_BUILDTYPE} \
--bindir ${@noprefix('bindir', d)} \
--sbindir ${@noprefix('sbindir', d)} \
--datadir ${@noprefix('datadir', d)} \
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 5838207e6b..fb232d414e 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -46,6 +46,20 @@ export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"
MESA_LLVM_RELEASE ?= "${LLVMVERSION}"
+# set the build type to either 'release' or 'debug'
+# the upstream mesa sources actually build a debug release by default
+# but here we assume the user will want a release build by default
+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 \
Therefore if the user doesn't do anything explicitly, a production buildtype
will be produced. However, if the user were to specify the following in their
conf/local.conf:
MESA_BUILD_TYPE = "debug"
I want mesa's buildtype to be "debugoptimized".
I don't want the user to specify the following in their conf/local.conf:
MESON_BUILDTYPE = "debugoptimized"
because that would cause *all* meson-built packages to switch to the
debugoptimized buildtype. I only want mesa's build to be debugoptimized.
However, the above doesn't work. If I set MESA_BUILD_TYPE to "hello" in my
conf/local.conf, then the build will flag it and error out asking me to
specify either 'release' or 'debug', which is great. But if I set
MESA_BUILD_TYPE to 'debug' the MESON_BUILDTYPE variable is always set to
"plain" regardless. So this task runs, but I guess it runs too late to
influence the MESON_BUILDTYPE variable?
So, how can I run this function earlier (?) so that it can set the
MESON_BUILDTYPE variable correctly? I tried the following:
diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index dc8c28963c..e1a13bbbf7 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -12,8 +12,9 @@ MESON_SOURCEPATH = "${S}"
def noprefix(var, d):
return d.getVar(var).replace(d.getVar('prefix') + '/', '', 1)
+MESON_BUILDTYPE ?= "plain"
MESONOPTS = " --prefix ${prefix} \
- --buildtype plain \
+ --buildtype ${MESON_BUILDTYPE} \
--bindir ${@noprefix('bindir', d)} \
--sbindir ${@noprefix('sbindir', d)} \
--datadir ${@noprefix('datadir', d)} \
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 5838207e6b..b302f8ee55 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -46,6 +46,20 @@ export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"
MESA_LLVM_RELEASE ?= "${LLVMVERSION}"
+# set the build type to either 'release' or 'debug'
+# the upstream mesa sources actually build a debug release by default
+# but here we assume the user will want a release build by default
+MESA_BUILD_TYPE ?= "release"
+def check_buildtype(d):
+ _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':
+ bb.plain("setting meson build type to debugoptimized")
+ return 'debugoptimized'
+ return 'plain'
+MESON_BUILDTYPE = "${@check_buildtype(d)}"
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
This will print out the bb.plain() message 16 times during parsing etc, it
will fail out if MESA_BUILD_TYPE is not one of 'release' or 'debug' (which is
good), but if this occurs, the error message is printed out twice plus a
python traceback, which might be scary to users.
The last thing I tried was the following:
diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index dc8c28963c..e1a13bbbf7 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -12,8 +12,9 @@ MESON_SOURCEPATH = "${S}"
def noprefix(var, d):
return d.getVar(var).replace(d.getVar('prefix') + '/', '', 1)
+MESON_BUILDTYPE ?= "plain"
MESONOPTS = " --prefix ${prefix} \
- --buildtype plain \
+ --buildtype ${MESON_BUILDTYPE} \
--bindir ${@noprefix('bindir', d)} \
--sbindir ${@noprefix('sbindir', d)} \
--datadir ${@noprefix('datadir', d)} \
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 5838207e6b..c265ffc246 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -46,6 +46,12 @@ export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"
MESA_LLVM_RELEASE ?= "${LLVMVERSION}"
+# set the build type to either 'release' or 'debug'
+# the upstream mesa sources actually build a debug release by default
+# but here we assume the user will want a release build by default
+MESA_BUILD_TYPE ?= "release"
+MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug', 'debugoptimized', 'plain', d)}"
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
This works perfectly, but it lacks the error checking and helpful messages of
the previous attempts.
Any thoughts on how I can have it all? (i.e. nice error checking and error
messages with the variable tweakable from conf/local.conf?
Best regards,
Trevor
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [yocto] variable and task/function timing
2019-12-11 7:18 variable and task/function timing Trevor Woerner
@ 2019-12-11 10:06 ` Nicolas Dechesne
2019-12-11 15:39 ` Trevor Woerner
0 siblings, 1 reply; 10+ messages in thread
From: Nicolas Dechesne @ 2019-12-11 10:06 UTC (permalink / raw)
To: Trevor Woerner; +Cc: Yocto list discussion
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
Of course, the parsing is dealing with all operators as well.
In a global conf file you set a variable for a specific recipe with
the _pn- operator. e.g. use:
MESON_BUILDTYPE_pn-bar = "debug"
to set MESON_BUILDTYPE to debug for the <bar> recipe.
>
> Conceptually this is what I want to do:
>
> Currently the meson build system (class) is hard-coded to always produce
> a buildtype of "plain", which are (basically) production builds. But
> there are other buildtypes that can be specified; such as
> "debugoptimized". I want a recipe to be able to influence the meson
> buildtype, and I want the user to be able to tweak this parameter from
> their conf/local.conf.
>
> Here's what I want to do:
>
> diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
> index dc8c28963c..e1a13bbbf7 100644
> --- a/meta/classes/meson.bbclass
> +++ b/meta/classes/meson.bbclass
> @@ -12,8 +12,9 @@ MESON_SOURCEPATH = "${S}"
> def noprefix(var, d):
> return d.getVar(var).replace(d.getVar('prefix') + '/', '', 1)
>
> +MESON_BUILDTYPE ?= "plain"
> MESONOPTS = " --prefix ${prefix} \
> - --buildtype plain \
> + --buildtype ${MESON_BUILDTYPE} \
> --bindir ${@noprefix('bindir', d)} \
> --sbindir ${@noprefix('sbindir', d)} \
> --datadir ${@noprefix('datadir', d)} \
> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
> index 5838207e6b..fb232d414e 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -46,6 +46,20 @@ export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"
>
> MESA_LLVM_RELEASE ?= "${LLVMVERSION}"
>
> +# set the build type to either 'release' or 'debug'
> +# the upstream mesa sources actually build a debug release by default
> +# but here we assume the user will want a release build by default
> +MESA_BUILD_TYPE ?= "release"
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 \
>
> Therefore if the user doesn't do anything explicitly, a production buildtype
> will be produced. However, if the user were to specify the following in their
> conf/local.conf:
>
> MESA_BUILD_TYPE = "debug"
>
> I want mesa's buildtype to be "debugoptimized".
>
> I don't want the user to specify the following in their conf/local.conf:
>
> MESON_BUILDTYPE = "debugoptimized"
use _pn- operator for that, as mentioned above.
>
> because that would cause *all* meson-built packages to switch to the
> debugoptimized buildtype. I only want mesa's build to be debugoptimized.
>
> However, the above doesn't work. If I set MESA_BUILD_TYPE to "hello" in my
> conf/local.conf, then the build will flag it and error out asking me to
> specify either 'release' or 'debug', which is great. But if I set
> MESA_BUILD_TYPE to 'debug' the MESON_BUILDTYPE variable is always set to
> "plain" regardless. So this task runs, but I guess it runs too late to
> influence the MESON_BUILDTYPE variable?
That is unexpected.. I would have thought it should work. 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.
>
> So, how can I run this function earlier (?) so that it can set the
> MESON_BUILDTYPE variable correctly? I tried the following:
>
> diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
> index dc8c28963c..e1a13bbbf7 100644
> --- a/meta/classes/meson.bbclass
> +++ b/meta/classes/meson.bbclass
> @@ -12,8 +12,9 @@ MESON_SOURCEPATH = "${S}"
> def noprefix(var, d):
> return d.getVar(var).replace(d.getVar('prefix') + '/', '', 1)
>
> +MESON_BUILDTYPE ?= "plain"
> MESONOPTS = " --prefix ${prefix} \
> - --buildtype plain \
> + --buildtype ${MESON_BUILDTYPE} \
> --bindir ${@noprefix('bindir', d)} \
> --sbindir ${@noprefix('sbindir', d)} \
> --datadir ${@noprefix('datadir', d)} \
> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
> index 5838207e6b..b302f8ee55 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -46,6 +46,20 @@ export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"
>
> MESA_LLVM_RELEASE ?= "${LLVMVERSION}"
>
> +# set the build type to either 'release' or 'debug'
> +# the upstream mesa sources actually build a debug release by default
> +# but here we assume the user will want a release build by default
> +MESA_BUILD_TYPE ?= "release"
> +def check_buildtype(d):
> + _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':
> + bb.plain("setting meson build type to debugoptimized")
> + return 'debugoptimized'
> + return 'plain'
> +MESON_BUILDTYPE = "${@check_buildtype(d)}"
> +
> EXTRA_OEMESON = " \
> -Dshared-glapi=true \
> -Dgallium-opencl=disabled \
>
> This will print out the bb.plain() message 16 times during parsing etc, it
> will fail out if MESA_BUILD_TYPE is not one of 'release' or 'debug' (which is
> good), but if this occurs, the error message is printed out twice plus a
> python traceback, which might be scary to users.
>
> The last thing I tried was the following:
>
> diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
> index dc8c28963c..e1a13bbbf7 100644
> --- a/meta/classes/meson.bbclass
> +++ b/meta/classes/meson.bbclass
> @@ -12,8 +12,9 @@ MESON_SOURCEPATH = "${S}"
> def noprefix(var, d):
> return d.getVar(var).replace(d.getVar('prefix') + '/', '', 1)
>
> +MESON_BUILDTYPE ?= "plain"
> MESONOPTS = " --prefix ${prefix} \
> - --buildtype plain \
> + --buildtype ${MESON_BUILDTYPE} \
> --bindir ${@noprefix('bindir', d)} \
> --sbindir ${@noprefix('sbindir', d)} \
> --datadir ${@noprefix('datadir', d)} \
> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
> index 5838207e6b..c265ffc246 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -46,6 +46,12 @@ export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"
>
> MESA_LLVM_RELEASE ?= "${LLVMVERSION}"
>
> +# set the build type to either 'release' or 'debug'
> +# the upstream mesa sources actually build a debug release by default
> +# but here we assume the user will want a release build by default
> +MESA_BUILD_TYPE ?= "release"
> +MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug', 'debugoptimized', 'plain', d)}"
> +
> EXTRA_OEMESON = " \
> -Dshared-glapi=true \
> -Dgallium-opencl=disabled \
>
> This works perfectly, but it lacks the error checking and helpful messages of
> the previous attempts.
>
> Any thoughts on how I can have it all? (i.e. nice error checking and error
> messages with the variable tweakable from conf/local.conf?
>
> Best regards,
> Trevor
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#47628): https://lists.yoctoproject.org/g/yocto/message/47628
> Mute This Topic: https://lists.yoctoproject.org/mt/68144480/1279857
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [nicolas.dechesne@linaro.org]
> -=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [yocto] variable and task/function timing
2019-12-11 10:06 ` [yocto] " Nicolas Dechesne
@ 2019-12-11 15:39 ` Trevor Woerner
2019-12-11 15:48 ` Richard Purdie
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Trevor Woerner @ 2019-12-11 15:39 UTC (permalink / raw)
To: Nicolas Dechesne; +Cc: Yocto list discussion
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.
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [yocto] variable and task/function timing
2019-12-11 15:39 ` Trevor Woerner
@ 2019-12-11 15:48 ` Richard Purdie
2019-12-11 15:51 ` Nicolas Dechesne
2019-12-11 16:26 ` Trevor Woerner
2019-12-11 15:49 ` Nicolas Dechesne
2019-12-19 16:16 ` Joel A Cohen
2 siblings, 2 replies; 10+ messages in thread
From: Richard Purdie @ 2019-12-11 15:48 UTC (permalink / raw)
To: Trevor Woerner, Nicolas Dechesne; +Cc: Yocto list discussion
On Wed, 2019-12-11 at 10:39 -0500, Trevor Woerner wrote:
> On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
> > > +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?)
Tasks run in isolation, if you change the datastore in a task it has no
way to get "seen" by other tasks. They're separate processes.
That is why the setVar in a task has no effect outside that task.
Cheers,
Richard
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [yocto] variable and task/function timing
2019-12-11 15:48 ` Richard Purdie
@ 2019-12-11 15:51 ` Nicolas Dechesne
2019-12-11 16:26 ` Trevor Woerner
1 sibling, 0 replies; 10+ messages in thread
From: Nicolas Dechesne @ 2019-12-11 15:51 UTC (permalink / raw)
To: Richard Purdie; +Cc: Trevor Woerner, Yocto list discussion
On Wed, Dec 11, 2019 at 4:48 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Wed, 2019-12-11 at 10:39 -0500, Trevor Woerner wrote:
> > On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
> > > > +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?)
>
> Tasks run in isolation, if you change the datastore in a task it has no
> way to get "seen" by other tasks. They're separate processes.
right... so my array is not 2D, but 3D then! but as i just said, i
missed the addtask in the first email.
>
> That is why the setVar in a task has no effect outside that task.
>
> Cheers,
>
> Richard
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [yocto] variable and task/function timing
2019-12-11 15:48 ` Richard Purdie
2019-12-11 15:51 ` Nicolas Dechesne
@ 2019-12-11 16:26 ` Trevor Woerner
1 sibling, 0 replies; 10+ messages in thread
From: Trevor Woerner @ 2019-12-11 16:26 UTC (permalink / raw)
To: Richard Purdie; +Cc: Nicolas Dechesne, Yocto list discussion
On Wed 2019-12-11 @ 03:48:51 PM, Richard Purdie wrote:
> On Wed, 2019-12-11 at 10:39 -0500, Trevor Woerner wrote:
> > On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
> > > > +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?)
>
> Tasks run in isolation, if you change the datastore in a task it has no
> way to get "seen" by other tasks. They're separate processes.
>
> That is why the setVar in a task has no effect outside that task.
Excellent, that explains a lot, thanks!
So in this case, the answer to the question of "when" is: never :-)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [yocto] variable and task/function timing
2019-12-11 15:39 ` Trevor Woerner
2019-12-11 15:48 ` Richard Purdie
@ 2019-12-11 15:49 ` Nicolas Dechesne
2019-12-11 16:41 ` Trevor Woerner
2019-12-19 16:16 ` Joel A Cohen
2 siblings, 1 reply; 10+ messages in thread
From: Nicolas Dechesne @ 2019-12-11 15:49 UTC (permalink / raw)
To: Trevor Woerner; +Cc: Yocto list discussion
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'))}"
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [yocto] variable and task/function timing
2019-12-11 15:49 ` Nicolas Dechesne
@ 2019-12-11 16:41 ` Trevor Woerner
2019-12-11 17:37 ` Nicolas Dechesne
0 siblings, 1 reply; 10+ messages in thread
From: Trevor Woerner @ 2019-12-11 16:41 UTC (permalink / raw)
To: Nicolas Dechesne; +Cc: Yocto list discussion
On Wed 2019-12-11 @ 04:49:27 PM, Nicolas Dechesne wrote:
> right.. I was confused, I missed a few things in your email (well, it
> was really long ;).
lol
Apparently writing long emails is therapeutic for me.
> > 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'))}"
I did propose a 3rd way (in the original email) which does work which is very
similar to what you're suggesting:
# set the build type to either 'release' or 'debug'
# the upstream mesa sources actually build a debug release by default
# but here we assume the user will want a release build by default
MESA_BUILD_TYPE ?= "release"
def check_buildtype(d):
_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':
#bb.plain("setting meson build type to debugoptimized")
return 'debugoptimized'
return 'plain'
MESON_BUILDTYPE = "${@check_buildtype(d)}"
The user experience is rather different though. Let's say the user sets the
following in conf/local.conf:
MESA_BUILD_TYPE = "hello"
Using the "addtask" method (which doesn't work) produces a very nice error
message:
$ bitbake mesa -c configure
Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
Loaded 2257 entries from dependency cache.
Parsing recipes: 100% |#######################################################################################################################| Time: 0:00:01
Parsing of 1528 .bb files complete (1524 cached, 4 parsed). 2259 targets, 103 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "opensuseleap-15.1"
TARGET_SYS = "arm-oe-linux-gnueabi"
MACHINE = "tinker-rk3288"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU = "hard"
meta-rockchip = "master:e8fd1f92ed59e0e71a7418779b912c5da342495c"
meta-tweaks = "master:b9184893949356a2da43bb2b5ec88dd573a5db0d"
meta = "master:093a1971f2ae12e1f514598da984f268607e550b"
meta-oe = "master:851321744e17e51aeb822a8d88c3532dffdf1cef"
Initialising tasks: 100% |####################################################################################################################| Time: 0:00:00
Sstate summary: Wanted 0 Found 0 Missed 0 Current 77 (0% match, 100% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: mesa-2_19.2.4-r0 do_check_build_type: unknown build type (hello), please set to either 'release' or 'debug'
ERROR: Logfile of failure stored in: /z/build-master/tinker-rk3288/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/mesa/2_19.2.4-r0/temp/log.do_check_build_type.12869
ERROR: Task (/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb:do_check_build_type) failed with exit code '1'
NOTE: Tasks Summary: Attempted 606 tasks of which 603 didn't need to be rerun and 1 failed.
Using the method proposed above produces:
$ bitbake mesa -c configure
Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
Loaded 2257 entries from dependency cache.
ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug' ETA: --:--:--
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Exception during build_dependencies for meson_do_configure
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug'
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Exception during build_dependencies for meson_do_configure
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb
ERROR: ExpansionError during parsing /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
Traceback (most recent call last):
File "Var <MESON_BUILDTYPE>", line 1, in <module>
File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa.inc", line 56, in check_buildtype(d=<bb.data_smart.DataSmart object at 0x7ffac8d0f4a8>):
if _buildtype not in ['release', 'debug']:
> bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/bitbake/lib/bb/__init__.py", line 108, in fatal:
mainlogger.critical(''.join(args), extra=kwargs)
> raise BBHandledException()
bb.data_smart.ExpansionError: Failure expanding variable MESON_BUILDTYPE, expression was ${@check_buildtype(d)} which triggered exception BBHandledException:
Summary: There were 4 WARNING messages shown.
Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [yocto] variable and task/function timing
2019-12-11 16:41 ` Trevor Woerner
@ 2019-12-11 17:37 ` Nicolas Dechesne
0 siblings, 0 replies; 10+ messages in thread
From: Nicolas Dechesne @ 2019-12-11 17:37 UTC (permalink / raw)
To: Trevor Woerner; +Cc: Yocto list discussion
On Wed, Dec 11, 2019 at 5:41 PM Trevor Woerner <twoerner@gmail.com> wrote:
>
> On Wed 2019-12-11 @ 04:49:27 PM, Nicolas Dechesne wrote:
> > right.. I was confused, I missed a few things in your email (well, it
> > was really long ;).
>
> lol
> Apparently writing long emails is therapeutic for me.
>
> > > 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'))}"
>
> I did propose a 3rd way (in the original email) which does work which is very
> similar to what you're suggesting:
>
> # set the build type to either 'release' or 'debug'
> # the upstream mesa sources actually build a debug release by default
> # but here we assume the user will want a release build by default
> MESA_BUILD_TYPE ?= "release"
> def check_buildtype(d):
> _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':
> #bb.plain("setting meson build type to debugoptimized")
> return 'debugoptimized'
> return 'plain'
> MESON_BUILDTYPE = "${@check_buildtype(d)}"
>
> The user experience is rather different though. Let's say the user sets the
> following in conf/local.conf:
>
> MESA_BUILD_TYPE = "hello"
>
> Using the "addtask" method (which doesn't work) produces a very nice error
> message:
>
> $ bitbake mesa -c configure
> Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
> Loaded 2257 entries from dependency cache.
> Parsing recipes: 100% |#######################################################################################################################| Time: 0:00:01
> Parsing of 1528 .bb files complete (1524 cached, 4 parsed). 2259 targets, 103 skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION = "1.44.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING = "opensuseleap-15.1"
> TARGET_SYS = "arm-oe-linux-gnueabi"
> MACHINE = "tinker-rk3288"
> DISTRO = "nodistro"
> DISTRO_VERSION = "nodistro.0"
> TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard"
> TARGET_FPU = "hard"
> meta-rockchip = "master:e8fd1f92ed59e0e71a7418779b912c5da342495c"
> meta-tweaks = "master:b9184893949356a2da43bb2b5ec88dd573a5db0d"
> meta = "master:093a1971f2ae12e1f514598da984f268607e550b"
> meta-oe = "master:851321744e17e51aeb822a8d88c3532dffdf1cef"
>
> Initialising tasks: 100% |####################################################################################################################| Time: 0:00:00
> Sstate summary: Wanted 0 Found 0 Missed 0 Current 77 (0% match, 100% complete)
> NOTE: Executing Tasks
> NOTE: Setscene tasks completed
> ERROR: mesa-2_19.2.4-r0 do_check_build_type: unknown build type (hello), please set to either 'release' or 'debug'
> ERROR: Logfile of failure stored in: /z/build-master/tinker-rk3288/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/mesa/2_19.2.4-r0/temp/log.do_check_build_type.12869
> ERROR: Task (/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb:do_check_build_type) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 606 tasks of which 603 didn't need to be rerun and 1 failed.
>
> Using the method proposed above produces:
>
> $ bitbake mesa -c configure
> Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
> Loaded 2257 entries from dependency cache.
> ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug' ETA: --:--:--
> WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Exception during build_dependencies for meson_do_configure
> WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
> ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug'
> WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Exception during build_dependencies for meson_do_configure
> WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb
> ERROR: ExpansionError during parsing /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
> Traceback (most recent call last):
> File "Var <MESON_BUILDTYPE>", line 1, in <module>
> File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa.inc", line 56, in check_buildtype(d=<bb.data_smart.DataSmart object at 0x7ffac8d0f4a8>):
> if _buildtype not in ['release', 'debug']:
> > bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
> if _buildtype == 'debug':
> File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/bitbake/lib/bb/__init__.py", line 108, in fatal:
> mainlogger.critical(''.join(args), extra=kwargs)
> > raise BBHandledException()
>
> bb.data_smart.ExpansionError: Failure expanding variable MESON_BUILDTYPE, expression was ${@check_buildtype(d)} which triggered exception BBHandledException:
>
>
> Summary: There were 4 WARNING messages shown.
> Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
then you could use an anonymous python function instead.
python () {
_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')
}
or something along these lines. that would be done during parsing, so
the variable should be set for all tasks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [yocto] variable and task/function timing
2019-12-11 15:39 ` Trevor Woerner
2019-12-11 15:48 ` Richard Purdie
2019-12-11 15:49 ` Nicolas Dechesne
@ 2019-12-19 16:16 ` Joel A Cohen
2 siblings, 0 replies; 10+ messages in thread
From: Joel A Cohen @ 2019-12-19 16:16 UTC (permalink / raw)
To: Trevor Woerner; +Cc: Nicolas Dechesne, Yocto list discussion
[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]
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@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:
>
...
> > 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
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
[-- Attachment #2: Type: text/html, Size: 4088 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-12-19 16:17 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-11 7:18 variable and task/function timing Trevor Woerner
2019-12-11 10:06 ` [yocto] " Nicolas Dechesne
2019-12-11 15:39 ` Trevor Woerner
2019-12-11 15:48 ` Richard Purdie
2019-12-11 15:51 ` Nicolas Dechesne
2019-12-11 16:26 ` Trevor Woerner
2019-12-11 15:49 ` Nicolas Dechesne
2019-12-11 16:41 ` Trevor Woerner
2019-12-11 17:37 ` Nicolas Dechesne
2019-12-19 16:16 ` Joel A Cohen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.