Openembedded Core Discussions
 help / color / mirror / Atom feed
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







  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