Fix for YB6217
cover Fix for YB6217
The following changes since commit 8b7116d25ed6255a03895d835e5a0560858ab496:
bitbake: Updated the the example 'bitbake -h' output to match the actual output, which has been recently patched to fix the '-S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER' option. (2014-07-22 08:33:25 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib roxana/YB6217
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=roxana/YB6217
Roxana Ciobanu (1):
bitbake.conf: move BB_NUMBER_THREADS and PARALLEL_MAKE to bitbake.conf
meta-yocto/conf/local.conf.sample | 22 ---------------------- meta-yocto/conf/local.conf.sample.extended | 23 +++++++++++++++++++++++ meta/conf/bitbake.conf | 4 ++++ 3 files changed, 27 insertions(+), 22 deletions(-)
Signature · 1 line
1.9.1
PATCH 1/1 bitbake.conf: move BB_NUMBER_THREADS and PARALLEL_MAKE to bitbake.conf
Currently, BB_NUMBER_THREADS and PARALLEL_MAKE default to unset and are set in local.conf. Now that we have the automatic probing, the default values can be set in bitbake.conf and an example of explicitly defining how many tasks to run can be moved to local.conf.sample.extended.
--- meta-yocto/conf/local.conf.sample | 22 ---------------------- meta-yocto/conf/local.conf.sample.extended | 23 +++++++++++++++++++++++ meta/conf/bitbake.conf | 4 ++++ 3 files changed, 27 insertions(+), 22 deletions(-)
meta-yocto/conf/local.conf.sample +0 -22
@@ -12,28 +12,6 @@ # variable as required. # -# Parallelism Options -# -# These two options control how much parallelism BitBake should use. The first -# option determines how many tasks bitbake should run in parallel: -# -#BB_NUMBER_THREADS ?= "4" -# -# Default to setting automatically based on cpu count -BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}" -# -# The second option controls how many processes make should run in parallel when -# running compile tasks: -# -#PARALLEL_MAKE ?= "-j 4" -# -# Default to setting automatically based on cpu count -PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}" -# -# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would -# be appropriate for example. - -# # Machine Selection # # You need to select a specific machine to target the build with. There are a selection
meta-yocto/conf/local.conf.sample.extended +23 -0
@@ -2,6 +2,29 @@ # certain recipes. #BBMASK = "" +# +# Parallelism Options +# +# These two options control how much parallelism BitBake should use. The first +# option determines how many tasks bitbake should run in parallel: +# +#BB_NUMBER_THREADS ?= "4" +# +# Default to setting automatically based on cpu count +#BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}" +# +# The second option controls how many processes make should run in parallel when +# running compile tasks: +# +#PARALLEL_MAKE ?= "-j 4" +# +# Default to setting automatically based on cpu count +#PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}" +# +# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would +# be appropriate for example. + + # eglibc configurability is used to reduce minimal image's size. # the all supported eglibc options are listed in DISTRO_FEATURES_LIBC # and disabled by default. Uncomment and copy the DISTRO_FEATURES_LIBC
meta/conf/bitbake.conf +4 -0
@@ -527,6 +527,10 @@ export TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE}" # Which flags to leave by strip-flags() in bin/build/oebuild.sh ? ALLOWED_FLAGS = "-O -mcpu -march -pipe" +# Default to setting automatically based on cpu count +BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}" +# Default to setting automatically based on cpu count +PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}" # Pass parallel make options to the compile task EXTRA_OEMAKE_prepend_task-compile = "${PARALLEL_MAKE} " PARALLEL_MAKEINST ??= "${PARALLEL_MAKE}"
Signature · 1 line
1.9.1
Re: [PATCH 1/1] bitbake.conf: move BB_NUMBER_THREADS and PARALLEL_MAKE to bitbake.conf
Quoted 1 line · Roxana Ciobanu
+BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
Thinking about this some more we probably need the assignments in bitbake.conf to be ??=, or to be moved further down the file to after local.conf has been evaluated (there's a section marked Weak Assignments, for exactly this situation).
The reasoning being that existing local.conf files will likely have e.g. BB_NUMBER_THREADS ?= 8 and the expectation is that this assignment will work. If bitbake.conf before local.conf has been loaded uses ?= then it will assign as the value hasn't been set, so then when local.conf is parsed the value has already been assigned and that assignment won't have an effect.
For consistency with the other variables that have moved to bitbake.conf, I think we should move it to the weak variables section in bitbake.conf and keep using ?=.
Ross