[OE-core] [PATCH 2/2] sanity.bbclass: Implement initial toolchain sanity checks
Richard Purdie
richard.purdie at linuxfoundation.org
Tue May 1 20:17:28 UTC 2012
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 at 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
More information about the Openembedded-core
mailing list