On Monday, 20. June 2011 16:31:55 Xiaofan Chen wrote:
> > The intention is to have
> > /usr/(local/)/include/ftdi.h for 0.1
> > /usr/(local/)/include/libftdi-1.0/ftdi.h for 1.0
> > /usr/(local/)/include/libftdi-x.x/ftdi.h for x.x for later versions
> >
> > and have
> > #include <ftdi.h>
> > #include<libftdi-1.0/ftdi.h>
> > #include<libftdi-x.x/ftdi.h>
> >
> > For the two latter cases,
> > #include<libftdi-1.0/libftdi.h>
> > #include<libftdi-x.x/libftdi.h>
> >
> > would also be fine, but i.m.h.o. bring no advantage.
>
> If 1.0 and 0.1 can not co-exist, I see no benefits of the
> above. If this is to differentiate library version, then it
> is actually much easier to have a new API called
> libftdi_getversion() which return the version at runtime.
Having the two co-exist makes it much easier for distributions
to ship both versions. Just think about what kind of mess it
would be if libusb 0.x and libusb 1.x couldn't co-exist...
I'm in favor of:
/usr/include/ftdi.h <- libftdi 0.x
/usr/include/libftdi-1.0/libftdi.h <- libftdi 1.x
This helps people to catch errors with the include path much easier.
Only cloud on the horizon: We might still stick to
/usr/include/libftdi-1.0 for compatibility reasons,
even when libftdi moved on to 2.x.
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
