libftdi Archives

Subject: RE: [RFC][PATCH] explicitly include libusb-1.0

From: xantares 09 <xantares09@xxxxxxxxxxx>
To: <libftdi@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 14 Jan 2013 10:19:35 +0000


> Date: Sun, 13 Jan 2013 21:06:13 +0100
> From: matthias.janke@xxxxxxxxxxxxxxxxxxxxxxx
> To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [RFC][PATCH] explicitly include libusb-1.0
>
> > On 2013-01-13 14:33, Matthias Janke wrote:
> > > Beeing lazy is one motivaton for the patch. The other one is that
> > > compiling an application is differnt from linking. When you link
> > > libusb is proxied by libftdi, since libftdi is linked against
> > > libusb, so on the linker cmd line there is only -lftdi1. So you
> > > don't care about
> > > libusb/x at all. But when you compile you have to include libusb
> > > explicitly even if you don't use it in your application. This
> > > breaks abstraction layers.
> >
> > IMHO it would be better to not include <libusb.h> at all when
> > compiling your application (unless the application needs it directly).
>
> Full ACK.
>
> > The attached patch removes said include from the exposed header
> > ftdi.h and instead includes libusb.h in the libftdi sources where
> > needed - ftdi.h itself did not need the declarations from libusb.h.
> > (Caveat: Only compile-tested, and only on Linux)
>
> That's probably the better fix. Tested with my projects and works fine
> on Linux.
>
> Thanks,
> Matthias
>

Hi,
Shouldn't the libftdi-config program provide the LIBUSB_INCLUDE_DIR location with --include ?
That's how I'd do it, and with cmake, the standard way is to provide a FTDIConfig/UseFTDI file, that way it can be included from find_package(FTDI NO_MODULE).
Maybe that could help.





libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx


Attachment: FTDIConfig.cmake.in
Description: Binary data

Current Thread