> Applied. Well, mostly. I've skipped the LIBFTDI_ASYNC_MODE part > is I think this will break existing builds as the variable > is not defined in userspace applications, right?
It seems weird to define an API in a public .h file which some of the public functions that are not implemented in the .c file. It think you're right: the proper way would be that the LIBFTDI_ASYNC_MODE definition does not appear at all in the .h file. However the .c file should always implement the public functions defined within the public .h file, and these functions should return an error when LIBFTDI_ASYNC_MODE is not defined, rather to lead to a static or dynamic link error. So yes, you'd better not to apply my change here, but something has to be done at .c level, I believe. However, the Python wrapper will fail for now, because the functions are declared, but not implemented. Maybe you want me to write another patch, here. > Otherwise I'll think it's sufficient to support it in libftdi 1.x only. Agreed. Anyway, libusb-1.x is the currently supported USB lib, so I think it's better to focus on libftdi-1.0. (My personal opinion is that as long as new features keep beeing added to libftdi-0.x, there is no incentive to move to libusb-1.x and the transition may last a lot longer; anyway I do not support the lib, so my personal opinion does not matter here: I'm fine with libftdi-1.x) Cheers, Manu -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
