From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: some variables not expanded corectly before BUILDCFG_VARS are shown
Date: Sat, 01 Dec 2012 14:34:37 +0000 [thread overview]
Message-ID: <1354372477.5970.2.camel@ted> (raw)
In-Reply-To: <20121130163855.GG3436@jama.jama.net>
On Fri, 2012-11-30 at 17:40 +0100, Martin Jansa wrote:
> Hi,
>
> when testing tune files I've noticed that TUNE_FEATURES are always shown
> the same, even when build uses different value set from local.conf:
>
> I've added DEFAULTTUNE to BUILDCFG_VARS to be sure:
> BUILDCFG_VARS = "BB_VERSION BUILD_SYS NATIVELSBSTRING TARGET_SYS MACHINE
> DISTRO DISTRO_VERSION TUNE_FEATURES DEFAULTTUNE TARGET_FPU"
>
> I was changing DEFAULTTUNE with machine override in local.conf or .inc
> file required from local.conf.
>
> $ grep DEFAULTTUNE conf/local.conf
> DEFAULTTUNE_om-gta02 = "arm920t"
> DEFAULTTUNE_nokia900 = "cortexa8t-neon"
> DEFAULTTUNE_tuna = "cortexa9t-neon"
>
> But the output at the beginning of build log was still the same.
> 1st is without any change to DEFAULTTUNE (so correctly armv4t and armv7a-neon)
> 2nd is with DEFAULTTUNE set in conf/local.conf with machine override
> 3rd is with default DEFAULTTUNE changed in tune-* file
>
> 2nd and 3rd correctly uses cortexa9t-neon/cortexa8t-neon/arm920t tune, but only 3rd shows it:
> nokia900/20121130041857.log:DEFAULTTUNE = "armv7a-neon"
> nokia900/20121130041857.log:TUNE_FEATURES = "armv7a vfp neon"
> nokia900/20121130101904.log:DEFAULTTUNE = "armv7a-neon"
> nokia900/20121130101904.log:TUNE_FEATURES = "armv7a vfp neon"
> nokia900/20121130135815.log:DEFAULTTUNE = "cortexa8t-neon"
> nokia900/20121130135815.log:TUNE_FEATURES = "armv7a vfp thumb neon cortexa8"
> om-gta02/20121130042112.log:DEFAULTTUNE = "armv4t"
> om-gta02/20121130042112.log:TUNE_FEATURES = "armv4 thumb"
> om-gta02/20121130102310.log:DEFAULTTUNE = "armv4t"
> om-gta02/20121130102310.log:TUNE_FEATURES = "armv4 thumb"
> om-gta02/20121130140126.log:DEFAULTTUNE = "arm920t"
> om-gta02/20121130140126.log:TUNE_FEATURES = "armv4 thumb arm920t"
> tuna/20121130041547.log:DEFAULTTUNE = "armv7a-neon"
> tuna/20121130041547.log:TUNE_FEATURES = "armv7a vfp neon"
> tuna/20121130101500.log:DEFAULTTUNE = "armv7a-neon"
> tuna/20121130101500.log:TUNE_FEATURES = "armv7a vfp neon"
> tuna/20121130135506.log:DEFAULTTUNE = "cortexa8t-neon"
> tuna/20121130135506.log:TUNE_FEATURES = "armv7a vfp thumb neon cortexa8"
>
> What's even more strange is that "thumb" override get applied in different order in 3rd build:
> $ bitbake-diffsigs tmp-eglibc/sstate-diff/13542[78]*/nokia900/cor*/libmad*/*do_con*
> basehash changed from 8ad5d9c1803fed09a89e626c07581cb1 to 7e316bb3c389fe3cda6652ac1476a883
> Variable EXTRA_OECONF value changed from
> -enable-speed --enable-shared --enable-fpm=arm --disable-aso --enable-fpm=default
> to
> -enable-speed --enable-shared --disable-aso --enable-fpm=default --enable-fpm=arm
> # because libmad has:
> # The ASO's don't take any account of thumb...
> EXTRA_OECONF_append_thumb = " --disable-aso --enable-fpm=default"
> EXTRA_OECONF_append_arm = " --enable-fpm=arm"
> But both 2srd and 3rd got --mtune=cortexa8.
>
> buildhistory.bbclass seems to read the same TUNE_PKGARCH (armv4t),
> all other builds are in arm920tt-oe-linux-gnueabi:
> $ find ~/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi
> /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi
> /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/bblayers
> /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/bblayers/1.0-r0
> /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/bblayers/1.0-r0/bblayers-1.0
> /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/bblayers/1.0-r0/temp
> /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/bblayers/1.0-r0/temp/run.buildhistory_commit.4401
> /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/bblayers/1.0-r0/temp/run.buildhistory_commit.6566
> /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/bblayers/1.0-r0/temp/run.buildhistory_commit.11843
>
> Any idea what is causing that?
Was this with or without the recent bitbake patch "data_smart: Improve
get_hash to account for overrides and key expansion" ? if without,
please see if that helps...
Cheers,
Richard
next prev parent reply other threads:[~2012-12-01 14:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 16:40 some variables not expanded corectly before BUILDCFG_VARS are shown Martin Jansa
2012-12-01 14:34 ` Richard Purdie [this message]
2012-12-01 17:36 ` Martin Jansa
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=1354372477.5970.2.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.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.