All of lore.kernel.org
 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 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.