All of lore.kernel.org
 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 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.