<div dir="ltr"><div class="gmail_quote"><div>Thanks for the reply.</div><div dir="ltr"><br></div><div dir="ltr">On Wed, Jul 25, 2018 at 4:58 PM Richard Purdie &lt;<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 2018-07-25 at 08:47 -0500, Matt Hoosier wrote:<br>
&gt; Quite a while ago I wrote the following message:<br>
&gt; On Tue, Jan 24, 2017 at 11:55 AM Matt Hoosier &lt;<a href="mailto:matt.hoosier@gmail.com" target="_blank">matt.hoosier@gmail.com</a><br>
&gt; &gt; wrote:<br>
&gt; &gt; In order to support a use-case that embeds information about the<br>
&gt; &gt; Git revision of Yocto itself that was used to make a build, I would<br>
&gt; &gt; like to run some arbitrary Python code and dump the results (Git<br>
&gt; &gt; SHA1&#39;s, tag names, etc) into a Bitbake variable.<br>
&gt; &gt; <br>
&gt; &gt; The idea is that the variable would get consumed in a do_install()<br>
&gt; &gt; task to populate some cookie-crumb file in the package payload.<br>
&gt; &gt; <br>
&gt; &gt; Something like:<br>
&gt; &gt; <br>
&gt; &gt;   DEPENDS = &quot;git-native&quot;<br>
&gt; &gt; <br>
&gt; &gt;   python () {<br>
&gt; &gt;     # This pseudocode isn&#39;t strictly functional for invoking Git,<br>
&gt; &gt; but you get the idea<br>
&gt; &gt;     d.setVar(&#39;GIT_INFO&#39;, subprocess.Popen([&#39;git&#39;, &#39;rev-list&#39;,<br>
&gt; &gt; ...]).communicate().stdout)<br>
&gt; &gt;   }<br>
&gt; &gt; <br>
&gt; &gt;   do_install () {<br>
&gt; &gt;     install -d ${D}/etc<br>
&gt; &gt;     echo &quot;${GIT_INFO}&quot; &gt; ${D}/etc/git-info.txt<br>
&gt; &gt;   }<br>
&gt; &gt; <br>
&gt; &gt; This all works on a fresh run, but Bitbake appears not to be<br>
&gt; &gt; evaluating the anonymous Python function on each execution. This<br>
&gt; &gt; leads it to have out-of-date information about the Git working copy<br>
&gt; &gt; when global state changes but happens not to impact the particular<br>
&gt; &gt; recipe holding this logic.<br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; <br>
&gt; The replies given at the time were very helpful in letting me<br>
&gt; accomplish my immediate goals, but I never really did get to the<br>
&gt; bottom of the real question:<br>
&gt;  <br>
&gt; &gt; Is there any trick available to cause the Python function to<br>
&gt; &gt; execute (and hence update the value of ${GIT_INFO} each Bitbake<br>
&gt; &gt; execution so that the up-to-the-moment contents of it filter into<br>
&gt; &gt; the calculation of the signature for do_install()? Or am I just<br>
&gt; &gt; trying a wrong-headed approach and doing something illegitimate? <br>
&gt; &gt; <br>
&gt; <br>
&gt; Some build systems I know of [1] that are based on hashes rather than<br>
&gt; timestamps have a way that you can inform the task execution engine<br>
&gt; to always poison the inputs to a certain task&#39;s up-to-dateness check.<br>
&gt; Is there anything in Bitbake that would allow a declaration to force<br>
&gt; such-and-such variable in a recipe always to be re-evaluated:<br>
&gt; <br>
&gt;   EXTERNALLY_INFLUENCED_VARIABLE = &quot;${@int(random.random() * 10)}&quot;<br>
&gt;   do_install[vardepsalwaysdirty] = &quot; EXTERNALLY_INFLUENCED_VARIABLE &quot;<br>
&gt; <br>
&gt;   do_install() {<br>
&gt;     echo &#39;${ EXTERNALLY_INFLUENCED_VARIABLE }&#39; &gt; ${D}/etc/stuff.txt<br>
&gt;   }<br>
&gt; <br>
&gt; Don&#39;t read too much into the example calling random() here. That&#39;s<br>
&gt; not really what I want to do; the point is just that the variable&#39;s<br>
&gt; value (though deterministic) isn&#39;t computed strictly from Bitbake<br>
&gt; metadata. So I&#39;m searching for a way to get the value of<br>
&gt; EXTERNALLY_INFLUENCED_VARIABLE to be re-computed each time Bitbake<br>
&gt; starts. If the computed value ends up matching what was seen on the<br>
&gt; last execution, then any dependent tasks wouldn&#39;t need re-run.<br>
&gt; <br>
&gt; Any ideas?<br>
&gt; <br>
&gt; [1] I&#39;m thinking particularly of Waf&#39;s hash-based task graph, which<br>
&gt; supports annotations that can be used to always cause a task to be<br>
&gt; re-run even if all the inputs feeding into it appear up-to-date.<br>
<br>
>From a bitbake perspective there are two things you need to ensure<br>
here, that the recipe gets reparsed at every execution</blockquote><div><br></div><div>Your advice about BB_DONT_CACHE does cause reparsing to get triggered. I can see that in logs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and that the<br>
task dependency exists. You have the dependency above and that is the<br>
easier piece to fix.<br></blockquote><div><br></div><div>But this part I&#39;m not seeing. The variable&#39;s value is always recalculated (sometimes more than once during a Bitbake run, but that&#39;s okay because it&#39;s idempotent), but the task only re-executes if the payload of the .bb file itself has changed. The blurb I wrote above:</div><div><br></div><div>  <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">do_install[vardepsalwaysdirty] = &quot;<span> </span></span><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;background-color:rgb(255,255,255);float:none;display:inline">EXTERNALLY_INFLUENCED_VARIABLE</span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>&quot;</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">is just some nonsense syntax I wrote there to illustrate my point. I don&#39;t think there&#39;s any var flag called &quot;vardepsalwaysdirty&quot;. Did you have this line in mind when you were saying that I&#39;d already gotten the task made dependent on the variable? Or were you just noting that the syntactic use of the variable inside of the task should engage the normal hash-based task-dependency calculation logic?</span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If the recipe is reparsed, the anon python reruns and the task hash<br>
recalculated.<br></blockquote><div><br></div><div>Is there anything extra I need to do to cause the reparsed variable&#39;s hash to cascade to the task?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If a recipe sets BB_DONT_CACHE, it will be reparsed upon each run and<br>
the hashes will dynamically change as you want. BB_SRCREV_POLICY !=<br>
&quot;cache&quot; uses that behind the scenes so that it can dynamically update<br>
srcrevs.<br>
<br>
Hope that helps...<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br></blockquote><div><br></div><div><br></div><div>Thanks! -Matt </div></div></div>