[oe] [RFC] base_less_or_equal() for numerical value testing in OE

[Paul Sokolovsky]

Hello Richard,

Tuesday, February 27, 2007, 10:49:01 PM, you wrote:

> On Tue, 2007-02-27 at 22:35 +0200, Paul Sokolovsky wrote:
>> This code was committed, as it doesn't affect any existing aspect of
>> OE. Please feel free to tweak it, and of course use!

> So its not really a RFC, is it? ;-)

  Disapprove is easy if it's wrong.

> I think base_conditional was added but left pretty dumb since we worried
> that if it was too generic it might get too many users. Inline python in
> the variables hits bitbake and parsing hard and its not something I'd
> like to encourage. Holger might have more specific comments. There are
> usually better ways to achieve the end result in a more bitbake like
> way. Also, personally I find the inline python really hard to read too.

> If we are going to do it, I'd prefer to see a set functions in their own
> class inherited by base.

> Yes, I realise I was guilty of adding a couple of these functions with
> task-base. They're mainly used in a couple of specific .bb files rather
> than the core classes and hopefully their usefulness outweights any
> speed penalty though...

  Well, that's good explanation from the point of view of birbake's
limitation we (still) have, but I'd like to approach from another side -
of what usecases we face. So, there was one case when
base_conditional() was used for checking ROM size too, but Marcin
replaced it with checks for specific machine models, exactly because
we had only ==, and not < or <=. And here's another case of fitting
angstrom-gpe-image into 16Mb (actual target is h3600, but I'd like
this time to do it in more scalable way then proliferate *_<machine>
stuff).

  I can quickly hand out 2 alternative solutions for this image size
problem: 1) define *-micro, *-normal, *-maxi bunch of images, 2)
assign each package a numeric priority, and package image based on
that (this "solution" is mentioned mostly for fun, of course).

  Well, both of them are more effortful than adding few base_*() at
right places. Solution #1 is still seems the most correct, of course,
but using conditionals may be seen as incremental step towards it.


  If we started on this topic (handling machine features in consistent
way, and establish best practices), let me dump another thing I ponder
for long time, before I'll start to code something - screen size problem.

  IMHO, "smallscreen" and "bigscreen" heuristic designators we use now
are the best thing we could have in our situation. There were
proposals on adding absolute screen properties, but IMHO, that
wouldn't give us much use, because 1) for most machines values will be
still approximate at best, and 2) we'd quickly decide that it's cool that
we have that info now, but bitbake sucks, and it's too inefficient to
actually use those info, so we shouldn't use it.

  And besides, simple "smallscreen" vs "bigscreen" dichotomy
corresponds to what packages actually provides in real life - mostly,
just 2 sets of icons, etc.

  What bothers me here however is that we uselessly package the same data
over and over again in machine-specific packages, plus each such recipe
must be modified for each new machine added to OE. Doesn't scale.

  What about following solution: define 2 "virtual" *archs* -
smallscreen and bigscreen. Make a convention that such archs can be
applied only to "data" ipk's. Then, a machine will just specify to
which virtual screen arch it belongs, like:

hx4700: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt bigscreen"
h4000: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt smallscreen"

  Voila, matching of actual bigsreen/smallscreen package will be done by
ipkg.

> Cheers,

> Richard 




-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com