On Wednesday, September 01, 2010 19:38:39 Xiaofan Chen wrote: > On Thu, Sep 2, 2010 at 4:57 AM, Mike Frysinger <[email protected]> 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.
