Re: Conditional Configuration Fragments

Re: Conditional Configuration Fragments

[Pierre Yves MORDRET]

On Monday 09 June 2014 09:56:20 Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> On Monday 09 June 2014 12:41:36 Bruce Ashfield wrote:
> > On 14-06-09 11:26 AM, Pierre Yves MORDRET wrote:
> > > Hello,
> > > 
> > > I really don't know whether this is feasible or not, but I'm trying to
> > > build a yocto image (custom image) with conditional configuration
> > > fragments.
> > > 
> > > Today I have 2 image type: one for deployment purpose and another for
> > > debug purpose. Debug images is only a superset of deployment image with
> > > additional debug capabilities: nothing else.
> > > 
> > > However now I would like to add additional linux kernel features to this
> > > debug image (ex: CONFIG_DEBUG_INFO=y).
> > > 
> > > I want to add this feature into debug image, but NOT in deployment image.
> > > 
> > > I was thinking to create a .bbappend to my linux .bb file, but again I
> > > don't see how to use .bbappend in a conditional way (based on image name
> > > for instance)
> > > 
> > > Do you have any idea to perform such request ?
> > 
> > Fragments are either just added to the SRC_URI or KERNEL_FEATURES via
> > the normal variable assignment rules.
> > 
> > So if you have something that you can test on (image/distro feature as
> > an example), you can use anonymous python and do a conditional
> > assignment.
> > 
> > Others on the list may have more elegant suggestions!
> 
> This can't work for what Pierre is asking for. You can't have a single recipe 
> built differently depending on what image is being built - our system does not 
> work that way. At a basic level, recipes create packages, and then the image 
> recipe selects which packages should go into the image.
> 
> Given that the kernel does not produce named packages in our system, I'm not 
> sure we currently have a way to build two different kernel recipes and select 
> one in one image and another in another image (which is the way we normally 
> handle this kind of requirement with other recipes.) Probably the only way to 
> do this is to have two completely separate build directories.

Many Thanks for your answers.
Thus I was thinking of making 2 separate linux.bb, one for deployment and the other for debug (i.e. linux-debug.bb) and update PREFERRED_PROVIDER_virtual/kernel accordingly.
But is there an automatic way to select proper .bb (linux.bb or linux-debug.bb) file like setting this variable(PREFERRED_PROVIDER_virtual/kernel) within the .bb image file ? Won't it work ?

Another option which is coming on top of my mind:
SRC_URI_append_<image-name> = " file://configuration_segment.cfg"
Is it something realistic and working ? 

Please advise
Many thanks in advance

Re: Conditional Configuration Fragments

[Bruce Ashfield]

On 14-06-10 11:11 AM, Pierre Yves MORDRET wrote:
> On Monday 09 June 2014 09:56:20 Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>> On Monday 09 June 2014 12:41:36 Bruce Ashfield wrote:
>>> On 14-06-09 11:26 AM, Pierre Yves MORDRET wrote:
>>>> Hello,
>>>>
>>>> I really don't know whether this is feasible or not, but I'm trying to
>>>> build a yocto image (custom image) with conditional configuration
>>>> fragments.
>>>>
>>>> Today I have 2 image type: one for deployment purpose and another for
>>>> debug purpose. Debug images is only a superset of deployment image with
>>>> additional debug capabilities: nothing else.
>>>>
>>>> However now I would like to add additional linux kernel features to this
>>>> debug image (ex: CONFIG_DEBUG_INFO=y).
>>>>
>>>> I want to add this feature into debug image, but NOT in deployment image.
>>>>
>>>> I was thinking to create a .bbappend to my linux .bb file, but again I
>>>> don't see how to use .bbappend in a conditional way (based on image name
>>>> for instance)
>>>>
>>>> Do you have any idea to perform such request ?
>>>
>>> Fragments are either just added to the SRC_URI or KERNEL_FEATURES via
>>> the normal variable assignment rules.
>>>
>>> So if you have something that you can test on (image/distro feature as
>>> an example), you can use anonymous python and do a conditional
>>> assignment.
>>>
>>> Others on the list may have more elegant suggestions!
>>
>> This can't work for what Pierre is asking for. You can't have a single recipe
>> built differently depending on what image is being built - our system does not
>> work that way. At a basic level, recipes create packages, and then the image
>> recipe selects which packages should go into the image.
>>
>> Given that the kernel does not produce named packages in our system, I'm not
>> sure we currently have a way to build two different kernel recipes and select
>> one in one image and another in another image (which is the way we normally
>> handle this kind of requirement with other recipes.) Probably the only way to
>> do this is to have two completely separate build directories.
>
> Many Thanks for your answers.
> Thus I was thinking of making 2 separate linux.bb, one for deployment and the other for debug (i.e. linux-debug.bb) and update PREFERRED_PROVIDER_virtual/kernel accordingly.
> But is there an automatic way to select proper .bb (linux.bb or linux-debug.bb) file like setting this variable(PREFERRED_PROVIDER_virtual/kernel) within the .bb image file ? Won't it work ?
>
> Another option which is coming on top of my mind:
> SRC_URI_append_<image-name> = " file://configuration_segment.cfg"
> Is it something realistic and working ?

The image name would have to be an OVERRIDE value for variables.
Last I checked it wasn't, but perhaps Paul can straighten out that
point as well :)

Cheers,

Bruce

>
> Please advise
> Many thanks in advance
>

Re: Conditional Configuration Fragments

[Paul Eggleton]

On Tuesday 10 June 2014 12:04:19 Bruce Ashfield wrote:
> On 14-06-10 11:11 AM, Pierre Yves MORDRET wrote:
> > On Monday 09 June 2014 09:56:20 Paul Eggleton 
<paul.eggleton@linux.intel.com> wrote:
> >> On Monday 09 June 2014 12:41:36 Bruce Ashfield wrote:
> >>> On 14-06-09 11:26 AM, Pierre Yves MORDRET wrote:
> >>>> Hello,
> >>>> 
> >>>> I really don't know whether this is feasible or not, but I'm trying to
> >>>> build a yocto image (custom image) with conditional configuration
> >>>> fragments.
> >>>> 
> >>>> Today I have 2 image type: one for deployment purpose and another for
> >>>> debug purpose. Debug images is only a superset of deployment image with
> >>>> additional debug capabilities: nothing else.
> >>>> 
> >>>> However now I would like to add additional linux kernel features to
> >>>> this
> >>>> debug image (ex: CONFIG_DEBUG_INFO=y).
> >>>> 
> >>>> I want to add this feature into debug image, but NOT in deployment
> >>>> image.
> >>>> 
> >>>> I was thinking to create a .bbappend to my linux .bb file, but again I
> >>>> don't see how to use .bbappend in a conditional way (based on image
> >>>> name
> >>>> for instance)
> >>>> 
> >>>> Do you have any idea to perform such request ?
> >>> 
> >>> Fragments are either just added to the SRC_URI or KERNEL_FEATURES via
> >>> the normal variable assignment rules.
> >>> 
> >>> So if you have something that you can test on (image/distro feature as
> >>> an example), you can use anonymous python and do a conditional
> >>> assignment.
> >>> 
> >>> Others on the list may have more elegant suggestions!
> >> 
> >> This can't work for what Pierre is asking for. You can't have a single
> >> recipe built differently depending on what image is being built - our
> >> system does not work that way. At a basic level, recipes create
> >> packages, and then the image recipe selects which packages should go
> >> into the image.
> >> 
> >> Given that the kernel does not produce named packages in our system, I'm
> >> not sure we currently have a way to build two different kernel recipes
> >> and select one in one image and another in another image (which is the
> >> way we normally handle this kind of requirement with other recipes.)
> >> Probably the only way to do this is to have two completely separate
> >> build directories.
> > 
> > Many Thanks for your answers.
> > Thus I was thinking of making 2 separate linux.bb, one for deployment and
> > the other for debug (i.e. linux-debug.bb) and update
> > PREFERRED_PROVIDER_virtual/kernel accordingly. But is there an automatic
> > way to select proper .bb (linux.bb or linux-debug.bb) file like setting
> > this variable(PREFERRED_PROVIDER_virtual/kernel) within the .bb image
> > file ? Won't it work ?
> > 
> > Another option which is coming on top of my mind:
> > SRC_URI_append_<image-name> = " file://configuration_segment.cfg"
> > Is it something realistic and working ?
> 
> The image name would have to be an OVERRIDE value for variables.
> Last I checked it wasn't, but perhaps Paul can straighten out that
> point as well :)

No, you can't do this, nor can you select PREFERRED_PROVIDER from the image. 
You cannot influence the building of other recipes from the image recipe at 
all.

As I said before, the only way to make this work would be if the kernel 
produced uniquely named packages that could be selected from the image; our 
kernel recipes don't currently do that though, and it would be a fairly major 
change in order to do that.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Conditional Configuration Fragments (Build Flavours)

[Tim O' Callaghan]

Hi,

This problem is similar to the 'build flavour' problem. That is you have a vanilla build, that you want to adjust to taste (e.g. different package configurations.) I'm migrating from 1.2 to 1.6, and I was about to send a post to the list about this, to see if anyone had solved it in an off the shelf-standard yocto way yet. 

The approach I use, is the inclusion of an externally generated file to set flavor specific configurations. This file is put in your build/conf, and then included in the recipes that need flavoring.
e.g. a sample flavour include file:
------ build/conf/flavor.inc -----
# create variable for flavouring
FLAVOUR_IMAGE_KERNELTYPE="DEBUG"
# IIRC export into global namespace, to that the build system uses is in hash generation, 
# and the variable is exported into the shell environment during build
export FLAVOUR_IMAGE_KERNELTYPE
------ cut -------

Then in the recipes that require flavouring you add:
-----
require flavour.inc
-----

You can then use the FLAVOUR_IMAGE_KERNELTYPE in the recipe for picking the right build options, or set other appropriate stuff. do_compile_prepend is useful for that. As the flavor variable is also exported in the build shell environment for the recipe, compile time decisions can be made for application pre-configuration purposes.

Am I right in assuming that 'build flavours' or something like it is not a standard feature? 

Tim.

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Paul Eggleton
Sent: dinsdag 10 juni 2014 18:09
To: Bruce Ashfield; Pierre Yves MORDRET
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Conditional Configuration Fragments

On Tuesday 10 June 2014 12:04:19 Bruce Ashfield wrote:
> On 14-06-10 11:11 AM, Pierre Yves MORDRET wrote:
> > On Monday 09 June 2014 09:56:20 Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> >> On Monday 09 June 2014 12:41:36 Bruce Ashfield wrote:
> >>> On 14-06-09 11:26 AM, Pierre Yves MORDRET wrote:
> >>>> Hello,
> >>>> 
> >>>> I really don't know whether this is feasible or not, but I'm 
> >>>> trying to build a yocto image (custom image) with conditional 
> >>>> configuration fragments.
> >>>> 
> >>>> Today I have 2 image type: one for deployment purpose and another 
> >>>> for debug purpose. Debug images is only a superset of deployment 
> >>>> image with additional debug capabilities: nothing else.
> >>>> 
> >>>> However now I would like to add additional linux kernel features 
> >>>> to this debug image (ex: CONFIG_DEBUG_INFO=y).
> >>>> 
> >>>> I want to add this feature into debug image, but NOT in 
> >>>> deployment image.
> >>>> 
> >>>> I was thinking to create a .bbappend to my linux .bb file, but 
> >>>> again I don't see how to use .bbappend in a conditional way 
> >>>> (based on image name for instance)
> >>>> 
> >>>> Do you have any idea to perform such request ?
> >>> 
> >>> Fragments are either just added to the SRC_URI or KERNEL_FEATURES 
> >>> via the normal variable assignment rules.
> >>> 
> >>> So if you have something that you can test on (image/distro 
> >>> feature as an example), you can use anonymous python and do a 
> >>> conditional assignment.
> >>> 
> >>> Others on the list may have more elegant suggestions!
> >> 
> >> This can't work for what Pierre is asking for. You can't have a 
> >> single recipe built differently depending on what image is being 
> >> built - our system does not work that way. At a basic level, 
> >> recipes create packages, and then the image recipe selects which 
> >> packages should go into the image.
> >> 
> >> Given that the kernel does not produce named packages in our 
> >> system, I'm not sure we currently have a way to build two different 
> >> kernel recipes and select one in one image and another in another 
> >> image (which is the way we normally handle this kind of requirement 
> >> with other recipes.) Probably the only way to do this is to have 
> >> two completely separate build directories.
> > 
> > Many Thanks for your answers.
> > Thus I was thinking of making 2 separate linux.bb, one for 
> > deployment and the other for debug (i.e. linux-debug.bb) and update 
> > PREFERRED_PROVIDER_virtual/kernel accordingly. But is there an 
> > automatic way to select proper .bb (linux.bb or linux-debug.bb) file 
> > like setting this variable(PREFERRED_PROVIDER_virtual/kernel) within 
> > the .bb image file ? Won't it work ?
> > 
> > Another option which is coming on top of my mind:
> > SRC_URI_append_<image-name> = " file://configuration_segment.cfg"
> > Is it something realistic and working ?
> 
> The image name would have to be an OVERRIDE value for variables.
> Last I checked it wasn't, but perhaps Paul can straighten out that 
> point as well :)

No, you can't do this, nor can you select PREFERRED_PROVIDER from the image. 
You cannot influence the building of other recipes from the image recipe at all.

As I said before, the only way to make this work would be if the kernel produced uniquely named packages that could be selected from the image; our kernel recipes don't currently do that though, and it would be a fairly major change in order to do that.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: Build Flavours: was Conditional Configuration Fragments

[Tim O' Callaghan]

The flavor file appears to have been broken by my mail client. Here is the example again for clarity. 

------ build/conf/flavor.inc -----
# create variable for flavouring
FLAVOUR_IMAGE_KERNELTYPE="DEBUG"

# IIRC export into global namespace, so that the build system uses is
# in hash generation and the variable is exported into the shell
# environment during build
export FLAVOUR_IMAGE_KERNELTYPE
------ cut -------

Essentially it sets a bitbake recipe variable then exports it. The export makes sure the recipe build shell environment has it set, and also that that build caching works, because the build environment variables are part of the hash creation. You need to manage flavour includes for every level of granularity, image, package-group, and recipes. Changing a flavour can cause a full rebuild if that flavour is included at image level.

Yocto currently manages the build infrastructure part of flavouring, I need to run external tooling to properly manage specific flavour includes at the moment, so that I can track what flavour is in what build.

Am I right in assuming that 'build flavours' or something like it is not yet a yocto feature?

Regards,

Tim.
-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Tim O' Callaghan
Sent: maandag 16 juni 2014 11:42
To: yocto@yoctoproject.org
Subject: Re: [yocto] Conditional Configuration Fragments (Build Flavours)

Hi,

This problem is similar to the 'build flavour' problem. That is you have a vanilla build, that you want to adjust to taste (e.g. different package configurations.) I'm migrating from 1.2 to 1.6, and I was about to send a post to the list about this, to see if anyone had solved it in an off the shelf-standard yocto way yet. 

The approach I use, is the inclusion of an externally generated file to set flavor specific configurations. This file is put in your build/conf, and then included in the recipes that need flavoring.
e.g. a sample flavour include file:
------ build/conf/flavor.inc -----
# create variable for flavouring
FLAVOUR_IMAGE_KERNELTYPE="DEBUG"
# IIRC export into global namespace, to that the build system uses is in hash generation, # and the variable is exported into the shell environment during build export FLAVOUR_IMAGE_KERNELTYPE
------ cut -------

Then in the recipes that require flavouring you add:
-----
require flavour.inc
-----

You can then use the FLAVOUR_IMAGE_KERNELTYPE in the recipe for picking the right build options, or set other appropriate stuff. do_compile_prepend is useful for that. As the flavor variable is also exported in the build shell environment for the recipe, compile time decisions can be made for application pre-configuration purposes.

Am I right in assuming that 'build flavours' or something like it is not a standard feature? 

Tim.

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Paul Eggleton
Sent: dinsdag 10 juni 2014 18:09
To: Bruce Ashfield; Pierre Yves MORDRET
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Conditional Configuration Fragments

On Tuesday 10 June 2014 12:04:19 Bruce Ashfield wrote:
> On 14-06-10 11:11 AM, Pierre Yves MORDRET wrote:
> > On Monday 09 June 2014 09:56:20 Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> >> On Monday 09 June 2014 12:41:36 Bruce Ashfield wrote:
> >>> On 14-06-09 11:26 AM, Pierre Yves MORDRET wrote:
> >>>> Hello,
> >>>> 
> >>>> I really don't know whether this is feasible or not, but I'm 
> >>>> trying to build a yocto image (custom image) with conditional 
> >>>> configuration fragments.
> >>>> 
> >>>> Today I have 2 image type: one for deployment purpose and another 
> >>>> for debug purpose. Debug images is only a superset of deployment 
> >>>> image with additional debug capabilities: nothing else.
> >>>> 
> >>>> However now I would like to add additional linux kernel features 
> >>>> to this debug image (ex: CONFIG_DEBUG_INFO=y).
> >>>> 
> >>>> I want to add this feature into debug image, but NOT in 
> >>>> deployment image.
> >>>> 
> >>>> I was thinking to create a .bbappend to my linux .bb file, but 
> >>>> again I don't see how to use .bbappend in a conditional way 
> >>>> (based on image name for instance)
> >>>> 
> >>>> Do you have any idea to perform such request ?
> >>> 
> >>> Fragments are either just added to the SRC_URI or KERNEL_FEATURES 
> >>> via the normal variable assignment rules.
> >>> 
> >>> So if you have something that you can test on (image/distro 
> >>> feature as an example), you can use anonymous python and do a 
> >>> conditional assignment.
> >>> 
> >>> Others on the list may have more elegant suggestions!
> >> 
> >> This can't work for what Pierre is asking for. You can't have a 
> >> single recipe built differently depending on what image is being 
> >> built - our system does not work that way. At a basic level, 
> >> recipes create packages, and then the image recipe selects which 
> >> packages should go into the image.
> >> 
> >> Given that the kernel does not produce named packages in our 
> >> system, I'm not sure we currently have a way to build two different 
> >> kernel recipes and select one in one image and another in another 
> >> image (which is the way we normally handle this kind of requirement 
> >> with other recipes.) Probably the only way to do this is to have 
> >> two completely separate build directories.
> > 
> > Many Thanks for your answers.
> > Thus I was thinking of making 2 separate linux.bb, one for 
> > deployment and the other for debug (i.e. linux-debug.bb) and update 
> > PREFERRED_PROVIDER_virtual/kernel accordingly. But is there an 
> > automatic way to select proper .bb (linux.bb or linux-debug.bb) file 
> > like setting this variable(PREFERRED_PROVIDER_virtual/kernel) within 
> > the .bb image file ? Won't it work ?
> > 
> > Another option which is coming on top of my mind:
> > SRC_URI_append_<image-name> = " file://configuration_segment.cfg"
> > Is it something realistic and working ?
> 
> The image name would have to be an OVERRIDE value for variables.
> Last I checked it wasn't, but perhaps Paul can straighten out that 
> point as well :)

No, you can't do this, nor can you select PREFERRED_PROVIDER from the image. 
You cannot influence the building of other recipes from the image recipe at all.

As I said before, the only way to make this work would be if the kernel produced uniquely named packages that could be selected from the image; our kernel recipes don't currently do that though, and it would be a fairly major change in order to do that.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Conditional Configuration Fragments

[Pierre Yves MORDRET]

[-- Attachment #1.1: Type: text/plain, Size: 930 bytes --]

Hello,

I really don't know whether this is feasible or not, but I'm trying to build a yocto image (custom image) with conditional configuration fragments.
Today I have 2 image type: one for deployment purpose and another for debug purpose. Debug images is only a superset of deployment image with additional debug capabilities: nothing else.
However now I would like to add additional linux kernel features to this debug image (ex: CONFIG_DEBUG_INFO=y).

I want to add this feature into debug image, but NOT in deployment image.
I was thinking to create a .bbappend to my linux .bb file, but again I don't see how to use .bbappend in a conditional way (based on image name for instance)

Do you have any idea to perform such request ?

Many thanks in advance


[cid:image003.png@01CF8407.F99988A0]

Pierre-Yves MORDRET | TINA: 166 7286 | Tel: +33 244027286 | Mobile: +33 611091514
UPD | Middleware Integrator


[-- Attachment #1.2: Type: text/html, Size: 5646 bytes --]

[-- Attachment #2: image003.png --]
[-- Type: image/png, Size: 9920 bytes --]

Re: Conditional Configuration Fragments

[Bruce Ashfield]

On 14-06-09 11:26 AM, Pierre Yves MORDRET wrote:
> Hello,
>
> I really don’t know whether this is feasible or not, but I’m trying to
> build a yocto image (custom image) with conditional configuration fragments.
>
> Today I have 2 image type: one for deployment purpose and another for
> debug purpose. Debug images is only a superset of deployment image with
> additional debug capabilities: nothing else.
>
> However now I would like to add additional linux kernel features to this
> debug image (ex: CONFIG_DEBUG_INFO=y).
>
> I want to add this feature into debug image, but NOT in deployment image.
>
> I was thinking to create a .bbappend to my linux .bb file, but again I
> don’t see how to use .bbappend in a conditional way (based on image name
> for instance)
>
> Do you have any idea to perform such request ?

Fragments are either just added to the SRC_URI or KERNEL_FEATURES via
the normal variable assignment rules.

So if you have something that you can test on (image/distro feature as
an example), you can use anonymous python and do a conditional
assignment.

Others on the list may have more elegant suggestions!

Bruce


>
> Many thanks in advance
>
> Description: Description: Description: Description: Description:
> Description: Description: Description: Description: Description:
> Description: Description: logo_big5
>
> Pierre-Yves MORDRET |TINA: 166 7286 |Tel: +33 244027286 | Mobile: +33
> 611091514
>
> UPD | Middleware Integrator
>
>
>

Re: Conditional Configuration Fragments

[Paul Eggleton]

On Monday 09 June 2014 12:41:36 Bruce Ashfield wrote:
> On 14-06-09 11:26 AM, Pierre Yves MORDRET wrote:
> > Hello,
> > 
> > I really don’t know whether this is feasible or not, but I’m trying to
> > build a yocto image (custom image) with conditional configuration
> > fragments.
> > 
> > Today I have 2 image type: one for deployment purpose and another for
> > debug purpose. Debug images is only a superset of deployment image with
> > additional debug capabilities: nothing else.
> > 
> > However now I would like to add additional linux kernel features to this
> > debug image (ex: CONFIG_DEBUG_INFO=y).
> > 
> > I want to add this feature into debug image, but NOT in deployment image.
> > 
> > I was thinking to create a .bbappend to my linux .bb file, but again I
> > don’t see how to use .bbappend in a conditional way (based on image name
> > for instance)
> > 
> > Do you have any idea to perform such request ?
> 
> Fragments are either just added to the SRC_URI or KERNEL_FEATURES via
> the normal variable assignment rules.
> 
> So if you have something that you can test on (image/distro feature as
> an example), you can use anonymous python and do a conditional
> assignment.
> 
> Others on the list may have more elegant suggestions!

This can't work for what Pierre is asking for. You can't have a single recipe 
built differently depending on what image is being built - our system does not 
work that way. At a basic level, recipes create packages, and then the image 
recipe selects which packages should go into the image.

Given that the kernel does not produce named packages in our system, I'm not 
sure we currently have a way to build two different kernel recipes and select 
one in one image and another in another image (which is the way we normally 
handle this kind of requirement with other recipes.) Probably the only way to 
do this is to have two completely separate build directories.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre