> 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 libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
