* some variables not expanded corectly before BUILDCFG_VARS are shown
@ 2012-11-30 16:40 Martin Jansa
2012-12-01 14:34 ` Richard Purdie
0 siblings, 1 reply; 3+ messages in thread
From: Martin Jansa @ 2012-11-30 16:40 UTC (permalink / raw)
To: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 3802 bytes --]
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?
Cheers,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: some variables not expanded corectly before BUILDCFG_VARS are shown
2012-11-30 16:40 some variables not expanded corectly before BUILDCFG_VARS are shown Martin Jansa
@ 2012-12-01 14:34 ` Richard Purdie
2012-12-01 17:36 ` Martin Jansa
0 siblings, 1 reply; 3+ messages in thread
From: Richard Purdie @ 2012-12-01 14:34 UTC (permalink / raw)
To: Martin Jansa; +Cc: openembedded-core
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: some variables not expanded corectly before BUILDCFG_VARS are shown
2012-12-01 14:34 ` Richard Purdie
@ 2012-12-01 17:36 ` Martin Jansa
0 siblings, 0 replies; 3+ messages in thread
From: Martin Jansa @ 2012-12-01 17:36 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 4662 bytes --]
On Sat, Dec 01, 2012 at 02:34:37PM +0000, Richard Purdie wrote:
> 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...
It was without this patch, only current master, but with this patch it
looks the same in log (I haven't checked if thumb/arm overrides are
still applied in different order, but output of
bitbake -e | grep OVERRIDES is the same for all 3 cases also with or
without this patch).
Cheers,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-12-01 17:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-30 16:40 some variables not expanded corectly before BUILDCFG_VARS are shown Martin Jansa
2012-12-01 14:34 ` Richard Purdie
2012-12-01 17:36 ` Martin Jansa
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.