<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 7:26 AM, 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"><div class="adM"><div class="h5"><br><div class="gmail_quote">On Tue, May 24, 2016 at 2:13 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Mon, 2016-05-23 at 13:34 -0700, Christopher Larson wrote:<br>
> From: Christopher Larson <<a href="mailto:chris_larson@mentor.com" target="_blank">chris_larson@mentor.com</a>><br>
><br>
> These files are treated as the contents of a bitbake variable, so<br>
> usual<br>
> bitbake variable references are supported. I considered using another<br>
> templating mechanism, for example the one used by yocto-layer, but<br>
> then we'd<br>
> end up largely mapping metadata variables to template fields anyway,<br>
> which is<br>
> a pointless indirection. Let bitbake expand the variables directly<br>
> instead.<br>
><br>
> This feature lets us, for example, reference ${APPEND} in --append,<br>
> and avoid<br>
> hardcoding the serial console tty in the wks file, and let the user's<br>
> changes<br>
> to APPEND affect wic the way they do the other image construction<br>
> mechanisms.<br>
><br>
> The template is read in and set in a variable at parse time, so<br>
> changes to the<br>
> variables referenced by the template will result in rebuilding the<br>
> image.<br>
><br>
> Signed-off-by: Christopher Larson <<a href="mailto:chris_larson@mentor.com" target="_blank">chris_larson@mentor.com</a>><br>
> ---<br>
> meta/classes/image_types.bbclass | 35<br>
> +++++++++++++++++++++++++++++++++++<br>
> 1 file changed, 35 insertions(+)<br>
><br>
> diff --git a/meta/classes/image_types.bbclass<br>
> b/meta/classes/image_types.bbclass<br>
> index dc681ae..caf8757 100644<br>
> --- a/meta/classes/image_types.bbclass<br>
> +++ b/meta/classes/image_types.bbclass<br>
> @@ -206,6 +206,16 @@ IMAGE_CMD_wic () {<br>
> }<br>
> IMAGE_CMD_wic[vardepsexclude] = "WKS_FULL_PATH WKS_FILES"<br>
><br>
> +python process_wks_template () {<br>
> + """Write out expanded template contents to WKS_FULL_PATH."""<br>
> + template_body = d.getVar('_WKS_TEMPLATE', True)<br>
> + if template_body:<br>
> + wks_file = d.getVar('WKS_FULL_PATH', True)<br>
> + with open(wks_file, 'w') as f:<br>
> + f.write(template_body)<br>
> +}<br>
> +do_image_wic[prefuncs] += 'process_wks_template'<br>
> +<br>
> # Rebuild when the wks file or vars in WICVARS change<br>
> USING_WIC = "${@bb.utils.contains_any('IMAGE_FSTYPES', 'wic ' + '<br>
> '.join('wic.%s' % c for c in '${COMPRESSIONTYPES}'.split()), '1', '',<br>
> d)}"<br>
> WKS_FILE_CHECKSUM = "${@'${WKS_FULL_PATH}:%s' %<br>
> os.path.exists('${WKS_FULL_PATH}') if '${USING_WIC}' else ''}"<br>
> @@ -302,3 +312,28 @@ IMAGE_TYPES_MASKED ?= ""<br>
> # The WICVARS variable is used to define list of bitbake variables<br>
> used in wic code<br>
> # variables from this list is written to <image>.env file<br>
> WICVARS ?= "BBLAYERS DEPLOY_DIR_IMAGE HDDDIR IMAGE_BASENAME<br>
> IMAGE_BOOT_FILES IMAGE_LINK_NAME IMAGE_ROOTFS INITRAMFS_FSTYPES<br>
> INITRD ISODIR MACHINE_ARCH ROOTFS_SIZE STAGING_DATADIR<br>
> STAGING_DIR_NATIVE STAGING_LIBDIR TARGET_SYS"<br>
> +<br>
> +python () {<br>
> + """Read in and set up wks file template for wic."""<br>
> + if d.getVar('USING_WIC', True):<br>
> + wks_file_u = d.getVar('WKS_FULL_PATH', False)<br>
> + wks_file = d.expand(wks_file_u)<br>
> + base, ext = os.path.splitext(wks_file)<br>
> + if ext == '.in' and os.path.exists(wks_file):<br>
> + wks_out_file = os.path.join(d.getVar('WORKDIR', True),<br>
> os.path.basename(base))<br>
> + d.setVar('WKS_FULL_PATH', wks_out_file)<br>
> + d.setVar('WKS_TEMPLATE_PATH', wks_file_u)<br>
> + d.setVar('WKS_FILE_CHECKSUM',<br>
> '${WKS_TEMPLATE_PATH}:True')<br>
> +<br>
> + try:<br>
> + with open(wks_file, 'r') as f:<br>
> + body = f.read()<br>
> + except (IOError, OSError) as exc:<br>
> + pass<br>
<br>
</div></div>I'm a little nervous about determinism here. Shouldn't it either find<br>
the referenced file or error?</blockquote></div><br></div></div>That's a fair point, I think I was concerned about parse time errors, since they tend to blow up into a lot of unpleasantness for the user, since parse time errors in classes can cause errors for multiple recipes. If no file is read in at parse time, there'll be no contents to write out, and we could then error when trying to build the image with wic, as no wks file will exist.<br><br clear="all"><div>Of course, the file being missing will change checksums for the image tasks, but I think that's reasonable.</div><div><br></div><div>Thoughts?</div></blockquote></div><br>I'll do a bit more testing on the behaviors and get back to you on that later. Thanks.<br>-- <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>