Yocto Project Discussions
 help / color / mirror / Atom feed
From: "Trevor Woerner" <twoerner@gmail.com>
To: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Cc: Yocto list discussion <yocto@yoctoproject.org>
Subject: Re: [yocto] variable and task/function timing
Date: Wed, 11 Dec 2019 11:41:32 -0500	[thread overview]
Message-ID: <20191211164132.GB13170@linux-uys3> (raw)
In-Reply-To: <CAP71WjyTvBT_XxUoZAVcdEzKZP0p1OKq62jF9zWfU7Y=pXfWEA@mail.gmail.com>

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.

  reply	other threads:[~2019-12-11 16:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2019-12-11 17:37         ` Nicolas Dechesne
2019-12-19 16:16     ` Joel A Cohen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191211164132.GB13170@linux-uys3 \
    --to=twoerner@gmail.com \
    --cc=nicolas.dechesne@linaro.org \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox