<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 2, 2016 at 7:23 PM, Christopher Larson <span dir="ltr"><<a href="mailto:kergoth@gmail.com" target="_blank">kergoth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Christopher Larson <<a href="mailto:chris_larson@mentor.com">chris_larson@mentor.com</a>><br>
<br>
This adds support for .<a href="http://wks.in" rel="noreferrer" target="_blank">wks.in</a> files as WKS_FILE.<br>
<br>
These files are treated as the contents of a bitbake variable, so usual<br>
bitbake variable references are supported. I considered using another<br>
templating mechanism, for example the one used by yocto-layer, but then we'd<br>
end up largely mapping metadata variables to template fields anyway, which is<br>
a pointless indirection. Let bitbake expand the variables directly instead.<br>
<br>
This feature lets us, for example, reference ${APPEND} in --append, and avoid<br>
hardcoding the serial console tty in the wks file, and let the user's changes<br>
to APPEND affect wic the way they do the other image construction mechanisms.<br>
<br>
The template is read in and set in a variable at parse time, so changes to the<br>
variables referenced by the template will result in rebuilding the image.<br>
<br>
It's been suggested that the name should better reflect how its contents are<br>
used, i.e. .bbin or so. I've also considered including something like 'bbv' or<br>
similar, to indicate its contents are that of a bitbake value. I think this<br>
should be discussed.<br>
<br>
I'd love to hear questions or comments on this. I think the value is clear,<br>
and it's something we need to solve, but I'd like to hear if others agree or<br>
disagree on that, and whether this implementation is appropriate.</blockquote><div><br></div><div>One downside to this approach is, afaik, that it's the first serious deviation between wic outside and wic as an image type. One alternative would be to parse the template at parse time to inject vars into WICVARS, but let wic process the template, but then of course a change to the template without re-running bitabke wouldn't update WICVARS and the written env files.</div></div>-- <br><div class="gmail_signature"><div dir="ltr">Christopher Larson<br>kergoth at gmail dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div></div>
</div></div>