[oe] Making bitbake directives conditional

[Chris Larson]

On Mon, Jan 25, 2010 at 2:32 PM, Michael Morrell
<Michael.Morrell at palm.com>wrote:

> >On Thursday 31 December 2009 19:55:52 Michael Morrell wrote:
> >> I have two quick OE questions.
> >>
> >> First, is it possible to use any of the "directives" in a bb file or
> conf
> >>  file based on a condition?  For example, can I "inherit" a class or use
> >>  "addtask" only under certain conditions.  I couldn't find a way to do
> >>  this.
>
> >The question is why do you need this? What would be your usecase? You
> could
> >achieve this with inherit ${MY_VAR} and then have MY_VAR be either "base"
> >(which is already included) or what you want... but this is kind of ugly
> >and hard to understand.
>
> Agreed this might work, but is ugly.
>
> One reason why I'd like to do this is so that "inherit package" which adds
> the package and package_write tasks isn't done if PACKAGES is empty (like
> for native package).  It is more efficient to not have these tasks scheduled
> and executed since they don't do anything in this case.
>

An alternative I've played with was avoiding the execution of any task whose
function is empty or nonexistant, and then emptying the definition of the
function in the metadata depending on the condition in question (i.e.
setVar("do_package", "") if not packages), but I don't really like that
approach either.  Yes, ideally we'd have a nice clean mechanism for
conditional definitions and conditional operations, but changes to the file
format need to be made carefully and with forethought or not at all
(alternatively, a new file format could be introduced).

I was thinking about implementing something like:
>
>  inherit <name> [if <cond>]
>

I vote against this.  Something like this would be good, yes, but not a
single syntax for a single bitbake recipe directive.. it should be a more
generic mechanism, in my opinion.

By the way, is there a difference between using "inherit" and assigning to
> the INHERIT variable?


Items listed in INHERIT are parsed into the global configuration metadata
prior to parsing any recipes, so are parsed before the recipe.  Items parsed
with 'inherit' are parsed *right there* in the file, so whether a variable
definition is before or after the inherit directive can make a difference.
 (Personally, I think we should move in the direction of ditching this
behavior, and move all of the classes between the config metadata & the
recipe).
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.