Bug #53808 for Device-USB: Convert Device::USB to libusb 1.0

Mon Jan 18 23:17:51 2010 cpan.wade [...] anomaly.org - Ticket created

Subject:

Convert Device::USB to libusb 1.0

It looks like 1.0 is now the recommended version of libusb (at least outside the Windows world). I may need to break this into multiple packages: * Device::USB::Legacy (?) to support 0.1 for now. * Device::USB for new 1.0 version. * Maybe break off the Win32 functionality separately. Or, I could keep Device::USB supporting 0.1 and make a new Device::LibUSB to support version 1.0. I'll need to think about it.

Mon Feb 22 15:01:40 2010 https://www.google.com/accounts/o8/id?id=AItOawlOQLT-_vyp3gltRz9gxT6UnXXY7Hf2afQ - Correspondence added

From:

Marin Purgar

I would vote for Device::LibUSB since in the API for the 0.1 branch function names are prefixed with usb_ and in the API for 1.0 branch function names are prefixed with libusb_. So, when/if there is the 1.0 version port to Win32 the existing Device::LibUSB should work with minimal changes (?). On Mon Jan 18 23:17:51 2010, GWADEJ wrote: Show quoted text

> It looks like 1.0 is now the recommended version of libusb (at least > outside the Windows world). > > I may need to break this into multiple packages: > > * Device::USB::Legacy (?) to support 0.1 for now. > * Device::USB for new 1.0 version. > * Maybe break off the Win32 functionality separately. > > Or, I could keep Device::USB supporting 0.1 and make a new > Device::LibUSB to support version 1.0. > > I'll need to think about it.

Sat Feb 27 17:49:24 2010 MSULLAND [...] cpan.org - Correspondence added

Hi. I vote for keeping the name Device::USB and jumping the version number into 1.xx symbolizing the move to the new libusb. Adding a extra notice in the documentation linking the different libusb versions with the corresponding device::usb versions. I think that approach would reduce the clutter that can occur if a separate Device::USB::Legacy or Windows namespace is introduced. This is also based on that there have been created packages that now uses Device::USB in their namespace, my own module included ( Device::USB::PCSensor::HidTEMPer). If you break your code into multiple namespaces we will also need to break our code into many namespaces, with the resulting clutter. On Mon Jan 18 23:17:51 2010, GWADEJ wrote: Show quoted text

> It looks like 1.0 is now the recommended version of libusb (at least > outside the Windows world). > > I may need to break this into multiple packages: > > * Device::USB::Legacy (?) to support 0.1 for now. > * Device::USB for new 1.0 version. > * Maybe break off the Win32 functionality separately. > > Or, I could keep Device::USB supporting 0.1 and make a new > Device::LibUSB to support version 1.0. > > I'll need to think about it.

Thu Apr 01 09:38:35 2010 jtreubig [...] hotmail.com - Correspondence added

From:

jtreubig [...] hotmail.com

On Mon Jan 18 23:17:51 2010, GWADEJ wrote: Show quoted text

> It looks like 1.0 is now the recommended version of libusb (at least > outside the Windows world). > > I may need to break this into multiple packages: > > * Device::USB::Legacy (?) to support 0.1 for now. > * Device::USB for new 1.0 version. > * Maybe break off the Win32 functionality separately. > > Or, I could keep Device::USB supporting 0.1 and make a new > Device::LibUSB to support version 1.0. > > I'll need to think about it.

Don't know if you've started the migration to 1.0, but I'll be glad to assist. Got a project that exposes a known bug in libusb 0 under Vista (BSoD). Using libusb-1.0 cures the bug, but I need Device::USB to complete the project. Let me know if you've got a repository for committing my changes, as I plan to start with 0.33 and go forward. Timing is immediate, so I'm beginning my work today.

Thu Apr 01 22:48:19 2010 cpan.wade [...] anomaly.org - Correspondence added

Show quoted text

> Don't know if you've started the migration to 1.0, but I'll be glad to > assist. Got a project that exposes a known bug in libusb 0 under Vista > (BSoD). Using libusb-1.0 cures the bug, but I need Device::USB to > complete the project. Let me know if you've got a repository for > committing my changes, as I plan to start with 0.33 and go forward. > Timing is immediate, so I'm beginning my work today.

I haven't freed up the tuits to work on the conversion yet. I am a little surprised that libusb-1.0 works on Vista. My understanding was that the Windows platforms were only supported by libusb-win32. If I'm wrong, that changes the landscape of the conversion significantly. The biggest problem I've had looking at the conversion is that the interface to libusb 1.0 appears to be very different from that for the 0.1 series. I was planning to take this opportunity to not only re-do all of the naming, but convert the interface to be more Perl-like. If you have time to work on it now, I'd be glad to see what you come up with. I'm afraid I won't have a chance for a while. G. Wade

Sat Sep 04 22:00:44 2010 dcw [...] gcm.com - Correspondence added

On Mon Jan 18 23:17:51 2010, GWADEJ wrote: Show quoted text

> It looks like 1.0 is now the recommended version of libusb (at least > outside the Windows world).

I tried building with the libusb-compat module on Mac OS X 10.6. (Caveat: this is my first attempt to program a mac since the 1980s. I'm more of a linux guy.) After much hacking around, I got pretty far, but when I run, I get this error. There is, indeed, a boot_Device__USB in _Inline/build/Device/USB/USB.c, so I don't know why it is looking in libUSB. }} nm _Inline/build/Device/USB/USB.o | grep boot 000000000000000c T _boot_Device__USB 000000000001a4a0 S _boot_Device__USB.eh not ok 1 - use Device::USB; # Failed test 'use Device::USB;' # at t/00-load.t line 8. # Tried to use 'Device::USB'. # Error: Had problems bootstrapping Inline module 'Device::USB' # # Can't find 'boot_Device__USB' symbol in /usr/local/lib/libUSB.dylib # at /Library/Perl/5.10.0/Inline.pm line 527 # # # at blib/lib/Device/USB.pm line 22 # Compilation failed in require at (eval 3) line 2, <DATA> line 1. # BEGIN failed--compilation aborted at t/00-load.t line 8.