Re: [PATCH 2/2] sanity.bbclass: Implement initial toolchain sanity checks

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2012-05-01 at 11:23 -0500, Peter Seebach wrote:
> On Tue, 1 May 2012 11:47:14 +0100
> Richard Purdie <richard.purdie@linuxfoundation.org> wrote: 
> > To be honest I'm really tempted to split this tuneabi stuff out into a
> > different class. I appreciate the OSVs need something but it probably
> > doesn't make sense with half an implementation sitting in the core
> > like this, particularly when the code is near impenetrable like the
> > above. I'm left wondering what TUNEABI is too...
> 
> The big reason I'd advocate for having it in the base stuff is that
> otherwise, all the OSVs are going to do their own and do it
> incompatibly.  The one thing worse than having one incomprehensible
> thing is having many incomprehensible things with subtly different
> semantics.
>  
> > > +                bb.warn("Got an unexpected '%s' in MULTILIBS." %
> > > pairs[0])
> 
> > Shouldn't this get added to the errors list?
> 
> Good question!  I was unable to find anything definite on the topic.
> My thought is, if everything has to be multilib:, there's no reason for
> the leading multilib: because it adds no information, so presumably
> there logically *could* be something else, but I haven't seen any and
> don't know about them.

Ah, I see what's happened here. This variable is used to append to
BBCLASSEXTEND where there are other values like "nativesdk" and
"native". Looking at the code, I think you should process
MULTILIB_VARIANTS.

The naming of the various multilib variables could probably do with
improvement in places :/.

Another good sanity check might be to look at the BBCLASSEXTEND values
and ensure they're in the list "native", "nativesdk", "multilib:xxx",
"cross".

> > > +            else:
> > > +                if pairs[1] == 'lib':
> > > +                    tune_error_set.append("The multilib 'lib' was
> > > specified, but that causes parse errors.")
> 
> > Hmm, it does?
> 
> Yeah, that was the thing I ran into when I tried a default config
> someone suggested; I thoughtfully corrected lib32 to lib, and libxcb
> exploded with two pages of Python stack traces and diagnostics.  If
> that's not intentional, I can drop this check and we can treat it as a
> package bug.

I think its a packaging bug. I'd be interested to see the error.

Cheers,

Richard