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
signature.asc
Description: This is a digitally signed message part.
|
