Re: IMAGE_TYPE vs IMAGE_TYPE(S)

[Henning Schild <henning.schild@siemens.com>]

Am Mon, 4 Jun 2018 09:16:46 +0200
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:

> On 2018-06-01 16:40, cedric_hombourger@mentor.com wrote:
> > Hello!
> > 
> > The documentation suggests that IMAGE_TYPE may be a list of images
> > to be built:
> > 
> >    | The `IMAGE_TYPE` variable contains the list of image types to
> > generate.
> > 
> > (ref: https://github.com/ilbers/isar/blob/master/doc/user_manual.md#image-type-selection)
> > 
> > It appears that one could set this to e.g. "ext4-img wic-img" to get
> > Isar to generate both an EXT4 image and a WIC image.
> > Alright.
> > 
> > But then how about this code:
> > 
> >    | if d.getVar('IMAGE_TYPE', True) == 'wic-img':
> >    |     d.appendVar('BUILDCHROOT_PREINSTALL',
> >    |                 d.getVar('BUILDCHROOT_PREINSTALL_WIC', True))
> > 
> > (ref: https://github.com/ilbers/isar/blob/master/meta/recipes-devtools/buildchroot/buildchroot.bb#L45)
> > 
> > The condition would be False for the example provided above and our
> > buildchroot missing vital tools such mkdosfs
> > 
> > We probably need to fix one or the other. What are your thoughts?  
> 
> While the above would be easy to adjust, it doesn't look to me like as
> if the rest of Isar is ready to support true IMAGE_TYPES semantic. I
> would suggest to adjust the doc for now so that it stops suggesting
> IMAGE_TYPE is like OE's IMAGE_TYPES. Patch welcome.

I agree. If you want another type just derive an image from your
existing one and override the IMAGE_TYPE. IMHO that is cleaner anyways
but would share less temporary results.

Henning

> Thanks for reporting!
> Jan
>