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 [email protected]
