[OE-core] [PATCHv 08/10] libusb*: import native support from meta-oe

[Martin Jansa]

On Sat, Mar 24, 2012 at 10:02:33AM +0000, Richard Purdie wrote:
> On Fri, 2012-03-23 at 23:30 +0100, Martin Jansa wrote:
> > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> > ---
> >  meta/recipes-support/libusb/libusb-compat_0.1.3.bb |    7 +++++--
> >  meta/recipes-support/libusb/libusb1_1.0.8.bb       |    2 ++
> >  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> Looking at this, it makes no sense. Why does our build system need to be
> trying to extract information from the *native* system's USB bus?
> 
> I can understand pango and cairo for font rendering in something like
> icons but libusb-native?

It's useful e.g. for native tools dfu-util, libftdi, usbpath

> Are you really sure we need this and have no other options as I can't
> see it actually being used...

Yes we can keep .bbappends with BBCLASSEXTEND = "native" in meta-oe, but
my point was that having 2 lines in .bb is less error-prone then
renaming .bbappends after version upgrade in oe-core.

> Looking at the other patches, I'm guessing they're broken without your
> PACKAGECONFIG change to fix -natives. A goal of this release is to have
> everything building and working that we ship. These 'simple'
> BBCLASSEXTENDs are likely going to change that. 

Those weren't failing for me (maybe just because their native deps are
"usually" built before them), gtk+-native was first where I've seen
libx11-native and libxrender-native missing in every build from scratch.

And this happens only since gtk+ was improved with PACKAGECONFIG to
respect DISTRO_FEAURES.. that's how I've found that bug.
 
> I don't really want to spend my weekend trying to fix and then test the
> PACKAGECONFIG change so I can merge these patches, particular as I've
> spent most of the week including the evenings just getting things to
> build. Arguably there could be other PACKAGECONFIG issue already I guess
> so we probably should fix that before release anyway. With -rc1 on
> Monday, that will be tricky :(.

I don't mind if you merge it after release or whenever. I'm using shr
branches anyway.

Maybe it would be usefull to put patches you think are good enough to be
merged after release to master-next or somewhere so that people know
that some patches are considered generaly OK, but not just before
release. Or create named branch for release.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120324/fdbf3c55/attachment-0002.sig>