libftdi Archives

Subject: Re: merging of libusb-1.0 support into mainline

From: Mike Frysinger <vapier@xxxxxxxxxx>
To: Xiaofan Chen <xiaofanc@xxxxxxxxx>
Cc: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Wed, 1 Sep 2010 23:47:10 -0400
On Wednesday, September 01, 2010 19:38:39 Xiaofan Chen wrote:
> On Thu, Sep 2, 2010 at 4:57 AM, Mike Frysinger <vapier@xxxxxxxxxx> wrote:
> > is there a list of pending issues holding up adding libusb-1.0 support to
> > the master libftdi tree ?  if there's a TODO or something that i can
> > help tackle, that would work.  having one released version to deal with
> > would make my life a lot easier as ive finished porting urjtag to
> > libusb-1.0 already.
> > 
> > (please cc me as i dont receive posts to this list)
> 
> Please refer to the following post from Thomas.
> http://developer.intra2net.com/mailarchive/html/libftdi/2010/msg00364.html
> 
> Todo:
> 1. Rename the library and header file. (not yet)
> 
> And this one:
> http://developer.intra2net.com/mailarchive/html/libftdi/2010/msg00257.html
> 
> So I will think it is not really a merge, but rather to make the two
> libraries can
> co-exist (like libusb and libusb-1.0). But I understand this may cause some
> extra work for project like urjtag.

i dont understand why this is necessary.  why is having libftdi-1.x require 
libusb-1.x isnt a big deal for distros ?  we have those packages in Gentoo 
right now.  for packages that still use libusb-0.x API, there is always the 
compat library.

if the ABI doesnt break, it's actually more of a pain to integrate different 
SONAMEs into binary distros.  a simple upgrade from libftdi-0.x to libftdi-1.x 
where one just replaces the other completely is a lot easier, and if it 
requires a new libusb, then that isnt a problem either.

if there is truly a desire to keep support for older distros which dont 
support libusb-1.x yet, then adding an internal compat layer isnt hard.  i did 
this for urjtag already.  so now the whole source uses libusb-1.x but if 
people are building against libusb-0.x, there is a local header to turn the 
0.x API into the 1.x API.

> 2. Remove autoconf support (resolved).

why ?  as i mentioned in the past, if people dont want to support autotools, 
then that's fine -- i can post patches to keep it up to date.  requiring cmake 
sucks, especially for me because there isnt any other low level / toolchain 
package with this dependency.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

Current Thread