Hi Michel,
On Wednesday, 23. January 2013 07:33:24 xantares 09 wrote:
> Yes, it's the same spirit as pkgconfig, and it's aimed at being used from
> cmake. It's very neat, look at the example: it's just 3 lines of code to
> add includes and link to libftdi/libusb from another cmake project.
>
> It could work for windows too, but as paths are not standard and dev
> packages are less common it's less obvious. On linux cmake finds
> automatically a package from command "find_package" if an XXXconfig.cmake
> lies in /usr/lib/cmake/XXX, else we need to pass
> "-DLibFTDI_DIR=/libftdi/install/path" to cmake. It may be cool to include
> it in a "devel" package so as for others to detect it without the burden
> of having to write a findXXX.cmake module (like libdfit does for USB1 :).
Ok, I've cherry-picked your patch. Thanks.
I'm not sure about the final installation destination of the
LibFTDIConfig.cmake file: If I understand it correctly,
it will always be placed in $PREFIX/lib/cmake.
I guess this breaks on 64bit boxes as the file should be placed in
$PREFIX/lib64, especially if a 64bit and 32bit version
of libftdi is installed at the same time?
My /usr/lib64/cmake directory looks like this:
[cmake]$ ls -1
Akonadi
KDE4Workspace
KDeclarative
KdepimLibs
libkcddb
libkcompactdisc
phonon
Should we also create a "libftdi" subdirectory?
(the lower case directory name is on purpose,
though I don't know if cmake will pick it up properly)
I'll also need to change the rpm .spec file accordingly.
I hate to rush such changes in before the final release :)
But it's good if the 1.0 final will contain improved cmake support.
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
