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

[Richard Purdie <rpurdie@rpsys.net>]

On Tue, 2007-02-27 at 23:31 +0200, Paul Sokolovsky wrote:
> > So its not really a RFC, is it? ;-)
> 
>   Disapprove is easy if it's wrong.

That isn't a good justification. Please ask first if you intend for
comments, then commit after discussion.

>   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.

I never said 2). I said we should keep in mind the impact on parsing
speed. We've gone to great lengths to improve it and I'm simply warning
there is a compromise. 

I don't want to see OE metadata turning into inlined python. If we find
we need to do that, something is wrong with the metadata format and we
should improve it.

The metadata format has been relatively static for a long time as the
bitbake developers have been conservative in certain areas. If we have a
need to improve it, I'm open to suggestions on that. Inlining python to
work around its limitations is not the correct solution.

>   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.

So automate those sites so they run off a machine specified variable.
You shouldn't have to hack the .bb's when adding a new machine (apart
from maybe things like fstab in base-files).

The actual packaging then becomes the only issue but that is only a
minor issue in the big picture.

I've slowly being try to remove machine specific packages too
(tslib-conf is no longer machine specific in the standard case).

> 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.

No. Adding architectures for every machine feature is just insane. You
need to find a better way to do it. Think about what you're suggesting
for a minute. 

Regards,

Richard