From: Henning Schild <henning.schild@siemens.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Cedric Hombourger <Cedric_Hombourger@mentor.com>,
<isar-users@googlegroups.com>
Subject: Re: [PATCH] wic-img: handle variables in .wks files
Date: Fri, 8 Feb 2019 17:27:58 +0100 [thread overview]
Message-ID: <20190208172758.38f7e6c1@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <723aeb7d-85be-0907-fa22-f41fd02e7daa@siemens.com>
Am Fri, 8 Feb 2019 15:31:48 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> On 08.02.19 15:28, [ext] Henning Schild wrote:
> > Not sure i get all the context right ... But if you are introducing
> > a template mechanism to generate .wks files, have a look at the
> > patches from Claudius that are currently pending.
> > He introduces a generic templating mechanism which may be useful for
> > generating .wks files as well.
>
> That is a different mechanism, not intended for patching recipe files
> (which wks files are). We align with OE here as far as I can see.
I would not agree. wks-Files are configuration for a tool we call in a
recipe, just like debian/ is for dpkg-buildpackage.
I guess the following should work with Claudius patches
SRC_URI+=file:///my.wks.tmpl and WKS_FILE=WORKDIR/my.wks
WICVARS are another way of passing configuration to wic, here it is
about all the bitbake vars that your plugins want to access, not about
vars that you might want to substitute in a .wks.tmpl before even
calling wic. Afaik wks files can not contain variables anymore.
But i guess we should all see the examples to understand where the code
is coming from and what it is for.
Henning
> Jan
>
> >
> > [PATCH v2 1/1] meta: added do_transform_template task as templating
> > system and switch
> >
> > You could give that a try and maybe still vote for or against that
> > mechanism. At the moment i would say it is likely to go in, and
> > consequently other/future templating mechanism will we be
> > questioned.
> >
> > Henning
> >
> > Am Fri, 8 Feb 2019 08:02:47 +0100
> > schrieb Cedric Hombourger <Cedric_Hombourger@mentor.com>:
> >
> >> Isar will now generate .wks from user-specified templates with
> >> variables such as $ROOTFS_TYPE or $ROOTFS_SIZE replaced with their
> >> values. Custom variables may be substituted by adding them to
> >> WKSVARS (WKSVAR += FOO)
> >>
> >> Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
> >> ---
> >> doc/user_manual.md | 2 ++
> >> meta/classes/wic-img.bbclass | 31 ++++++++++++++++++++++++++++++-
> >> 2 files changed, 32 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/doc/user_manual.md b/doc/user_manual.md
> >> index ebc31c6..ea3b4bd 100644
> >> --- a/doc/user_manual.md
> >> +++ b/doc/user_manual.md
> >> @@ -197,6 +197,8 @@ A bootable disk image is generated if you set
> >> IMAGE_TYPE to 'wic-img'. Behind th $ bitbake
> >> multiconfig:qemuamd64-stretch:isar-image-base ```
> >>
> >> +Note: `.wks` files may use the ROOTFS_SIZE and ROOTFS_TYPE
> >> variables (as well as any other bitbake variables added to
> >> WKSVARS). + In order to run the EFI images with `qemu`, an EFI
> >> firmware is required and available at the following address:
> >> https://github.com/tianocore/edk2/tree/3858b4a1ff09d3243fea8d07bd135478237cb8f7
> >> diff --git a/meta/classes/wic-img.bbclass
> >> b/meta/classes/wic-img.bbclass index 76602d8..16bbc53 100644
> >> --- a/meta/classes/wic-img.bbclass
> >> +++ b/meta/classes/wic-img.bbclass
> >> @@ -81,6 +81,32 @@ addtask do_rootfs_wicenv after
> >> do_copy_boot_files before do_wic_image do_rootfs_wicenv[vardeps]
> >> += "${WICVARS}" do_rootfs_wicenv[prefuncs] = 'set_image_size'
> >>
> >> +WKSVARS += "ROOTFS_SIZE ROOTFS_TYPE"
> >> +
> >> +python do_rootfs_wksenv () {
> >> + wksvars = d.getVar('WKSVARS', True)
> >> + if not wksvars:
> >> + return
> >> +
> >> + stdir = d.getVar('STAGING_DIR', True)
> >> + outdir = os.path.join(stdir, d.getVar('MACHINE', True),
> >> 'imgdata')
> >> + bb.utils.mkdirhier(outdir)
> >> + basename = d.getVar('IMAGE_BASENAME', True)
> >> + with open(os.path.join(outdir, basename) + '-wks.sh', 'w') as
> >> envf:
> >> + for var in wksvars.split():
> >> + value = d.getVar(var, True)
> >> + if value:
> >> + envf.write('%s="%s" \\\n' % (var, value.strip()))
> >> + envf.write("envsubst '")
> >> + for var in wksvars.split():
> >> + envf.write('$%s ' % var)
> >> + envf.write("'\n")
> >> +}
> >> +
> >> +addtask do_rootfs_wksenv after do_rootfs_wicenv before
> >> do_wic_image +do_rootfs_wksenv[vardeps] += "${WKSVARS}"
> >> +do_rootfs_wksenv[prefuncs] = 'set_image_size'
> >> +
> >> WIC_IMAGE_FILE ="${DEPLOY_DIR_IMAGE}/${IMAGE_FULLNAME}.wic.img"
> >>
> >> do_build[stamp-extra-info] = "${DISTRO}-${DISTRO_ARCH}"
> >> @@ -99,8 +125,11 @@ do_wic_image() {
> >> export BUILDDIR=${BUILDDIR}
> >> export MTOOLS_SKIP_CHECK=1
> >>
> >> + /bin/sh
> >> ${STAGING_DIR}/${MACHINE}/imgdata/${IMAGE_BASENAME}-wks.sh \
> >> + <${WKS_FULL_PATH}
> >>> ${BUILDCHROOT_DIR}/tmp/${IMAGE_FULLNAME}.wks +
> >> sudo -E chroot ${BUILDCHROOT_DIR} \
> >> - ${ISARROOT}/scripts/wic create ${WKS_FULL_PATH} \
> >> + ${ISARROOT}/scripts/wic create /tmp/${IMAGE_FULLNAME}.wks
> >> \ --vars "${STAGING_DIR}/${MACHINE}/imgdata/" \
> >> -o /tmp/${IMAGE_FULLNAME}.wic/ \
> >> -e ${IMAGE_BASENAME} ${WIC_CREATE_EXTRA_ARGS}
> >
>
prev parent reply other threads:[~2019-02-08 16:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-08 7:02 Cedric Hombourger
2019-02-08 7:42 ` Jan Kiszka
2019-02-08 7:44 ` Hombourger, Cedric
2019-02-08 7:48 ` Jan Kiszka
2019-02-08 7:53 ` Jan Kiszka
2019-02-08 7:55 ` Hombourger, Cedric
2019-02-08 11:32 ` Hombourger, Cedric
2019-02-08 13:50 ` Hombourger, Cedric
2019-02-08 19:13 ` [PATCH v2] wic-img: import support for .wks.in files from oe-core Cedric Hombourger
2019-02-15 17:43 ` Maxim Yu. Osipov
2019-02-08 14:28 ` [PATCH] wic-img: handle variables in .wks files Henning Schild
2019-02-08 14:31 ` Hombourger, Cedric
2019-02-08 14:31 ` Jan Kiszka
2019-02-08 16:27 ` Henning Schild [this message]
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=20190208172758.38f7e6c1@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=Cedric_Hombourger@mentor.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox