On Thursday, September 02, 2010 03:44:05 Thomas Jarosch wrote:
> On Thursday, 2. September 2010 05:47:10 Mike Frysinger wrote:
> > 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.
> The "ftdi_context" structure was expanded in libftdi-1.x,
> IMHO this won't be ABI compatible.
yes & no. i see the items were added to the end -- good. and the allocation
is always handled by libftdi ? so users will not be doing malloc(struct
ftdi_context) but rather ftdi_new() ?
in terms of the function of these new fields (async accesses), it isnt like
people would have to change their code in order to work with the new library
even if they never utilize async functionality ? in other words, if i had an
app today that doesnt use async stuff and works fine, then i shouldnt have to
make any source changes to it so that it works with the newer libftdi-1.0 ?
if that's the case, then backwards compatibility should be maintained. the
emphasis in the world is on newer ABIs being compatible with older programs.
there is no guarantee of newer programs working with older libraries.
> > 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.
> The keyword here is "older". If the distro is too old to use libusb 1.x,
> then it can also stick to an libftdi 0.x version and don't update it
i was going to suggest that too. glad you're already thinking in that
it's not like libftdi-0.18 is "bad". if that were the last libftdi release
that supported libusb-0.x, i dont think that'd be a problem for people.
Description: This is a digitally signed message part.