[yocto] 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 at yoctoproject.org [mailto:yocto-bounces at yoctoproject.org] On Behalf Of Tim O' Callaghan
Sent: maandag 16 juni 2014 11:42
To: yocto at 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 at yoctoproject.org [mailto:yocto-bounces at yoctoproject.org] On Behalf Of Paul Eggleton
Sent: dinsdag 10 juni 2014 18:09
To: Bruce Ashfield; Pierre Yves MORDRET
Cc: yocto at 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 at 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 at yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
_______________________________________________
yocto mailing list
yocto at yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto