[oe] RFC: strip "-native" from $S for native packages automatically (bug 1856)

[Richard Purdie]

On Sat, 2008-01-26 at 01:51 +0100, Michael 'Mickey' Lauer wrote:
> On Friday 25 January 2008 12:33:39 Rolf Leggewie wrote:
> > Hi,
> >
> > I elicit your comments on bug 1856, especially comment3.
> >
> > The bug is about stripping "-native" automatically from the S variable
> > for native packages since it will hardly ever occur that a tar ball will
> > unpack to $PN-native-$PV/  This would save us resetting $S manually for
> > native packages all the time.  Koen suggested the fix to go into
> > native.bbclass. When I revisited the bug today, I thought this must be
> > as easy to fix as simply adding
> >
> >   export S=`echo $S|sed s/\-native\-/\-/`
> 
> That looks like an infinite recursion to me.
> S:= ... may work, but I don't like launching a shell for that.

Agreed, it won't work and := is not appropriate either, I still maintain
that := should be used with caution and only when people really
understand what its implications are.

> If we really want to have that (I'm -0 on that), I would rather propose
> 
> S = ${@"%s/%s" % ( bb.data.getVar("WORKDIR", d, 1), bb.data.getVar("P", d, 1).replace( "-native", "" ) ) }

Would it be worth adding syntax to bitbake for this kind of operation,
something like:

S *= "${S}-native"

?

I don't know if many people had noticed but I've recently added a lot of
-sdk packages to poky and this would be useful for sdk.bbclass too. The
sdk packages are really useful but the .bb files are tedious, just like
-native.

I've been thinking about the -native/-sdk problem again and I'd like to
try and plan an extension to bitbake to help with this. The idea would
be to have a list of "extension" classes like sdk and native. During
parsing bitbake bitbake would first parse as usual but then it would
automatically "inherit native" and then "inherit sdk" for each .bb file.

The extension classes could be named in some variable
BB_PARSING_EXTENSION_CLASSES = "native sdk" or I wondered if we add a
new type of file (.bbextclass?). The variable approach would mean a
package could easily choose not to have this behaviour or to extend
it...

This does assume we can reduce native recipes to "inherit native" but
with suitable changes to native.bbclass that should be possible?

Cheers,

Richard