From: Mike Looijmans <mike.looijmans@topic.nl>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: How to find out why my do_compile depends on $MACHINE
Date: Tue, 6 Oct 2015 14:55:16 +0200 [thread overview]
Message-ID: <5613C4B4.9000908@topic.nl> (raw)
In-Reply-To: <1444051353.5118.20.camel@linuxfoundation.org>
On 05-10-15 15:22, Richard Purdie wrote:
> On Mon, 2015-10-05 at 13:49 +0200, Mike Looijmans wrote:
>> On 05-10-15 12:18, Richard Purdie wrote:
>>> On Mon, 2015-10-05 at 11:34 +0200, Mike Looijmans wrote:
...
>> For the bigger picture:
>>
>> If I have a recipe that says:
>>
>> X = "x"
>>
>> And I refactor it a bit to read:
>>
>> Y = "x"
>> X = "${Y}"
>>
>> What is the logic behind having to rebuild the package now? Why does the
>> 'source' of the contents matter to the hash? It won't generate different
>> output, regardless whether X is 'calculated' or just 'constant'.
>>
>> In particular, I've noticed this happening when switching between AUTOREV and
>> a fixed revision in a recipe.
>
> This is simply just the way the system is designed. It checksums the
> intermediate steps as well as the endpoints. I guess in the above
> example the system might do "export Y" for example.
In that case, "Y" would end up in the package's sstate hash, and hence it
would rebuild when Y changes.
I have a workaround now, multiple workarounds actually, but I'm trying to
understand why the system would be designed this way. Currently I'm tempted to
splatter X[vardepvalue]="${X}" all over the place just to get rid of this
annoying behaviour.
> There are alternative ways to do things but its simply not the way
> things were implemented. If you do need to collapse the dependency
> chain, you can use vardepvalue which was added for that reason. There
> are only a small number of places you really need to do that.
Lets make things more concrete. My distro.conf now reads:
FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}"
Say I want to build packages with varying optimization levels. I consider
myself pretty smart, so in this distro.conf file, I change that line to:
OPT_LEVEL ?= "-O2"
FULL_OPTIMIZATION = "${OPT_LEVEL} -pipe ${DEBUG_FLAGS}"
So now I can replace the optimization level of some packages by simply
changing the OPT_LEVEL variable.
Nice, but this will trigger a rebuild of ALL packages, event though the build
flags did not change at all!
I can't think of any reason why this would be desirable. Why is it designed
this way?
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
next prev parent reply other threads:[~2015-10-06 12:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 9:34 How to find out why my do_compile depends on $MACHINE Mike Looijmans
2015-10-05 10:18 ` Richard Purdie
2015-10-05 11:49 ` Mike Looijmans
2015-10-05 12:46 ` Martin Jansa
2015-10-05 13:22 ` Richard Purdie
2015-10-06 12:55 ` Mike Looijmans [this message]
2015-10-06 15:40 ` Christopher Larson
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=5613C4B4.9000908@topic.nl \
--to=mike.looijmans@topic.nl \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.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