<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 5:55 AM, Mike Looijmans <span dir="ltr"><<a href="mailto:mike.looijmans@topic.nl" target="_blank">mike.looijmans@topic.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05-10-15 15:22, Richard Purdie wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 2015-10-05 at 13:49 +0200, Mike Looijmans wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05-10-15 12:18, Richard Purdie wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 2015-10-05 at 11:34 +0200, Mike Looijmans wrote:<br>
</blockquote></blockquote></blockquote></span>
...<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For the bigger picture:<br>
<br>
If I have a recipe that says:<br>
<br>
X = "x"<br>
<br>
And I refactor it a bit to read:<br>
<br>
Y = "x"<br>
X = "${Y}"<br>
<br>
What is the logic behind having to rebuild the package now? Why does the<br>
'source' of the contents matter to the hash? It won't generate different<br>
output, regardless whether X is 'calculated' or just 'constant'.<br>
<br>
In particular, I've noticed this happening when switching between AUTOREV and<br>
a fixed revision in a recipe.<br>
</blockquote>
<br>
This is simply just the way the system is designed. It checksums the<br>
intermediate steps as well as the endpoints. I guess in the above<br>
example the system might do "export Y" for example.<br>
</blockquote>
<br></span>
In that case, "Y" would end up in the package's sstate hash, and hence it would rebuild when Y changes.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are alternative ways to do things but its simply not the way<br>
things were implemented. If you do need to collapse the dependency<br>
chain, you can use vardepvalue which was added for that reason. There<br>
are only a small number of places you really need to do that.<br>
</blockquote>
<br></span>
Lets make things more concrete. My distro.conf now reads:<br>
<br>
FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}"<br>
<br>
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:<br>
<br>
OPT_LEVEL ?= "-O2"<br>
FULL_OPTIMIZATION = "${OPT_LEVEL} -pipe ${DEBUG_FLAGS}"<br>
<br>
So now I can replace the optimization level of some packages by simply changing the OPT_LEVEL variable.<br>
<br>
Nice, but this will trigger a rebuild of ALL packages, event though the build flags did not change at all!<br>
<br>
I can't think of any reason why this would be desirable. Why is it designed this way?</blockquote></div><br>This behavior has bugged me for quite a while, I'd love to see this change in the long term, assuming Richard isn't opposed to it. We should care about the results, not how we got there, generally.<br>-- <br><div class="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>