Sure, sounds good. On Mon, Oct 1, 2018 at 2:03 PM Richard Purdie < [email protected]> wrote:
> On Mon, 2018-10-01 at 11:12 +0000, Martin Jansa wrote: > > * currently it's used only by image.bbclass, image_types.bbclass and > > meta/recipes-core/images/build-appliance-image_15.0.0.bb > > but if it's needed by some recipe which isn't itself an image, then > > it's useful in bitbake.conf, e.g. we have a recipe for creating > > VirtualBox appliances which combines .wic.vmdk with .ovf file to > > create .zip with appliance, but for that we need the filename of > > .wic.vmdk which now contains IMAGE_NAME_SUFFIX > > https://github.com/webOS-ports/meta-webos-ports/blob/4980ce52a43ac6 > > 897657602810313af359f0b839/meta-luneos/recipes-core/images/luneos- > > emulator-appliance.inc#L24 > > > > * we were hardcoding .rootfs suffix where needed, but for quite long > > time it's configurable with IMAGE_NAME_SUFFIX and might not match: > > > > commit 380ee36811939d947024bf78de907e3c071b834f > > Author: Patrick Ohly <[email protected]> > > Date: Mon Mar 7 18:07:52 2016 +0100 > > > > image creation: allow overriding .rootfs suffix > > > > Signed-off-by: Martin Jansa <[email protected]> > > --- > > meta/classes/image_types.bbclass | 6 ------ > > meta/conf/bitbake.conf | 6 ++++++ > > 2 files changed, 6 insertions(+), 6 deletions(-) > > You could make this argument for many of the class variables, with > other code needing some small piece and we end up importing a ton of > stuff into bitbake.conf and global scope. My worry is this isn't > scalable and leads to code which is hard to disentangle. > > How about we create imagevars.conf which the class could include, or > other users could include without pulling in the main class? > > Cheers, > > Richard > > >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
