Manu,
On Saturday, 19. June 2010 23:09:21 Emmanuel Blot wrote:
> I gave a try, but I eventually came to the conclusion it may bring
> more build issues, as other libraries (such as libusb dependency)
> should also be built with the same set of targets - otherwise the
> overall build would fail.
> As long as libftdi is not distributed as a pre-packaged binary, I
> think it is safer to build for a single target.
Ok
> >> > Does this also work if we move the
> >> > "+include_directories(${Boost_INCLUDE_DIRS})" part
> >> > to the Boost specific code in ftdipp/CMakeLists.txt?
>
> Done, along with some other changes:
> https://gist.github.com/d87e3ab79b3421587a13
> I've fixed several build issues, see the commit message.
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?
btw: The patch looks way more harmless if diffed with
"ignore space change" ;)
> > Do you want this to be part of 0.18?
>
> It would be nice.
> I did not check whether it could cause a build issue on some Linux hosts.
The patch you sent me is for libftdi 1.0. It doesn't apply out of the box
for libftdi 0.18. My current plan is to build the libftdi 0.18 tarball
around Wednesday/Friday. If building libftdi 0.x on Mac OS X is an
issue for you, feel free to send another patch. Otherwise I'll think
it's sufficient to support it in libftdi 1.x only.
> I've also fixed the warning messages due to the 64-bit integer print out,
> see: https://gist.github.com/fd7e926a518ce8cbbc31
> I guess a better fix should be done for compilers/environments where
> 64-bit integers are not expressed as "long long integers"
Applied, thanks.
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
