Added FindLibrary files for various libraries

[larshg]

Instead of hard coding in a sub depend folder.

Updated to to use PKG-config first to find and fallback to Cmake if pkg-config is not found.

I have only tested it on windows.

[goldhoorn]

Linux provides pkg_config scripts for libturbojpeg and for libusb, therefore i would like to not go for the cmake apporach to finding packages. I proposed in #90 another approach which uses pkg_config and keep the old system (for migration time) alive.

[larshg]

I'm afraid that windows normally doesn't include pkg_config and seems quite a hassle to get it working, but the cmake script can be made to use pgk_config if on linux (also mac?) and then use the cmake module search on windows?

[goldhoorn]

Could do such a separation, but the main- dev's should decide in
general if they are agree to swich to a generic way to find packages
instead of the current-local-include.

If your's got merged (or agreed), i agree to take care of the linux build...

Best,
Matthias

On 18.11.2014 09:18, Lars wrote:

I'm afraid that windows normally doesn't include pkg_config and seems
quite a hassle to get it working, but the cmake script can be made to
use pgk_config if on linux (also mac?) and then use the cmake module
search on windows?

—
Reply to this email directly or view it on GitHub
#68 (comment).

[floe]

I think we all agree that we need a generic approach, especially now that all required libraries (except libusb) are available in distro repositories. However, I think this overlaps with PR #68 ?

[christiankerl]

could we make our own FindTurboJPEG script in the cmake_modules folder, which on Linux/Mac basically uses pkg_config and on Windows uses a variable specifying the path? For libusb we have the issue that we need the patched version on Linux...

[floe]

Of course, I thought this is exactly what #68 proposes?

[floe]

Sorry, I confused the PRs...

[goldhoorn]

So to collect:

Windows:
Using self-provided FindScripts, but add option to give-paths manually

Linux:
using package_config

General:
Keep instead of #90 headers as they are and extend include-dir in CMakeLists
But i think the separation of finding modules should be done in the toplevel CMakeLists and not in the FindScripts the find scripts should only find the deps and not do the os-separaion.

If all agree:
larshg: would you do the Find-Scripts if you finished with that i creating my PR ontop of yours.. (please give me therefore access to your repro)

[larshg]

As for now, there is also a need for a patched libusb version on windows with this pr https://github.com/libusbx/libusbx/pull/164 , but that is up to the user to make sure that a proper libusb is installed.

@goldhoorn : I just skimmed through the pr and I can see that I have hardcoded a path to turbojpeg, that should probably be changed. I'll try to look into it soon.
I'll give you access.

[goldhoorn]

@larshg: could you please contact me by email (see my profile) when you finished, you have not published you email, i don't want to flood this PR with discusson between us.

[larshg]

Updated this a lot to work with recent master and making first use of PKG-config as requested by @goldhoorn.

How are the various libraries located on Linux?
All headers in /usr/include
and libraries in /lib/?

[goldhoorn]

(short answer)

The core-concept:
reallce core os stuff:
/lib
/include
user stuff:
/usr/include/
/usr/lib/
machine-local user stuff:
/usr/local/include/
/usr/local/lib/

and so on..

But moreworese the distributions install in different sub-folder, thats what pkg-config was intended for. The user can give a multiple base-paths for package-config (.pc) files. The pc-file is generated during the build of these libraries and points to the correct paths. These paths are then used by cmake...

[larshg]

Hey
This has now been updated to match both my needs and @goldhoorn - so if people could try it out and give feedback would be nice.

@christiankerl Can you review it?

There might be needed some paths updates in the Linux part, since I haven't yet installed a linux test machine. This is only if the libraries are not found by pkg-config though.

edit: Just noticed that build was added to the ignore list - want it removed?

Lars

[goldhoorn]

I successfully tested this PR on Ubuntu 14.04 and Debian testing with all dependancies installed externally (either by apt-get or by providing the related pkg-config files (which are part of the libs itself).

Ack for merge from my side

[floe]

Sorry for the long silence, was just preparing to merge this, but has it been tested on MacOS X so far?

[goldhoorn]

I don't have a macos currently sorry :-(

[gaborpapp]

OSX errors:

-- checking for module 'libusb'
--   package 'libusb' not found
CMake Error at /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:340 (message):
  A required package was not found
Call Stack (most recent call first):
  /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:502 (_pkg_check_modules_internal)
  CMakeLists.txt:6 (pkg_check_modules)
  CMakeLists.txt:51 (auto_detect_lib)

libusb is installed, but macports does not provide a pkgconfig file for it.

CMake Error at cmake_modules/FindTurboJPEG.cmake:18 (message):
Could not find turbojpeg.h - Try define TurboJPEG_ROOT as a system
variable

Even when TurboJPEG_ROOT is set to depends/libjpeg_turbo with full path.

[goldhoorn]

@xlz however it's simliar

[11:16:14 goldhoorn rock.core]$ dpkg -L libusb-1.0-0-dev
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libusb-1.0-0-dev
/usr/share/doc/libusb-1.0-0-dev/changelog.Debian.gz
/usr/share/doc/libusb-1.0-0-dev/changelog.gz
/usr/share/doc/libusb-1.0-0-dev/copyright
/usr/share/doc/libusb-1.0-0-dev/README
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libusb-1.0.a
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/libusb-1.0.pc
/usr/include
/usr/include/libusb-1.0
/usr/include/libusb-1.0/libusb.h
/usr/lib/x86_64-linux-gnu/libusb-1.0.so

[larshg]

@gaborpapp can you try set TurboJPEG_ROOT to the full path? That's what the root environment variables are for.

@floe I only have a windows running atm. but I am semi working on getting a linux eviroment working also - but for now thats more @goldhoorn area in this pr.

I'll add the depends/"libraries" paths to all the findLibrary cmake files soonish.

[goldhoorn]

I'm in standby for testing ping me, but not have (yet) the time to contribute actively.

[gaborpapp]

@larhsg TurboJPEG_ROOT was set to the full path. I just meant it pointed to the depends/libjpeg_turbo directory.

[larshg]

@gaborpapp whats the subfolder in libjpeg_turbo? bin,classes,doc,include and lib?

[gaborpapp]

something like that, yes.

libjpeg_turbo
├── bin
├── include
├── lib
├── man
└── share

[larshg]

@gaborpapp I just relooked the find cmake script for libjpegturbo and it didn't look in the enviroment path variable for non-windows systems.

I have added changes here https://github.com/larshg/libfreenect2/tree/FixFindLibJPEG - can you try it out?

[gaborpapp]

@larshg now it works for turbojpeg. thanks. would be nice to have a fallback location in the depends folder for the other libs as well if the pkg-config check fails, which still happens on OSX for libusb.

[larshg]

I guess if you can set an environment variable that would be fine? We can also add the depend folder as a search path until/if the depends get removed at some time - what do you think @floe ?

I'll look at the libusb also @gaborpapp - its also your local depends folder? - whats the folder structure for include and lib directory?

[floe]

Yes, I would suggest to simply put depends/libusb and depends/glfw into the search path for the time being. I think it will take a while until we can drop the dedicated libusb build.

[larshg]

oki and the 3 libraries are expected to be placed in depends with these subfolders: libjpeg_turbo, libusb and glfw? I'll add those 3 paths in their respective findlib cmake files.

[gaborpapp]

yes, if it works with an environment variable, that is fine. Maybe a bit easier to work with if the folders are in the search path as @floe suggests.

libusb was installed with macports just like glfw and opencv. the output from pkg-config:

$ pkg-config --list-all | grep 'glfw\|opencv\|libusb'
opencv                              OpenCV - Open Source Computer Vision Library
libusb-1.0                          libusb-1.0 - C API for USB device access from Linux, Mac OS X, Windows and OpenBSD/NetBSD userspace
glfw3                               GLFW - A multi-platform library for OpenGL, window and input

maybe it is because the libusb-1.0?

It is also in the depends folder, because I ran install_deps.sh/install_mac.sh.
Folder structure in depends for libusb:

libusb
├── include
└── lib

[floe]

Just to clarify, will it still work on Windows if I just rename LibUSB to LibUSB-1.0?

[larshg]

if works if you also rename the cmake file for locating liusb. ie. findlibusb.cmake to findlibusb-1.0.cmake.

[goldhoorn]

Can you guys create a experimental branch on the repro so that we can
test this?

On 04.06.2015 14:54, Lars wrote:

if works if you also rename the cmake for locating liusb. ie.
findlibusb.cmake to findlibusb-1.0.cmake.

—
Reply to this email directly or view it on GitHub
#68 (comment).

[floe]

I've pushed a new branch cmake_libusb_1.0 to the main repository.

[larshg]

The branch works fine on my setup.

[goldhoorn]

No i'm completely confused i don't have a kinect at my hand just now.
The proposed branch is compiling but links to another libusb version.
I don't know if this version had the required patches:

Current chosen one (with patch):
/lib/x86_64-linux-gnu/libusb-1.0.so.0.1.0
https://packages.debian.org/jessie/libusb-1.0-0

Previously choosen:
/lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4
https://packages.debian.org/jessie/libusb-0.1-4

These packages are a mess...

[kohrt]

With the current master or libusb branch I always get this error

CMake Error at CMakeLists.txt:151 (if):
  if given arguments:
    "STREQUAL" "FALSE"
  Unknown arguments specified

sovled it by checking if defined if(NOT DEFINED ${GLFW3_FOUND} OR ${GLFW3_FOUND} STREQUAL "FALSE")

The other problem is, that it now uses the system libusb, with is version 1.0.17. This version does not contain the needed patch. So there need to be a check for the version, for everything lower than 1.0.19-1 (or what ever is says on debian) use the one from the depends folder.

[floe]

Please check new branch glfw3_fix.

[larshg]

Works fine here.

[floe]

@larshg good to know, thanks.
@goldhoorn right now, there is no existing ready-made package which actually contains the exact libusb version we require. You can successfully compile and link libfreenect against libusb-1.0.17 and 1.0.19, but at runtime, you still need the custom-built libusb-1.0.so for things to work.

[gaborpapp]

@floe, if there's no working libusb why does cmake search for it instead of using the one in depends?

OSX build issues with the current master:

I had to set TurboJPEG_ROOT manually, cmake didn't fall back to depends\libjpeg_turbo.
Although libusb is picked up now, there's an error with LIBUSB_INCLUDE_DIR.

$ export TurboJPEG_ROOT=full-path-to/depends/libjpeg_turbo
$ cmake ..
-- The C compiler identification is AppleClang 6.0.0.6000057
-- The CXX compiler identification is AppleClang 6.0.0.6000057
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test LIBFREENECT2_THREADING_STDLIB
-- Performing Test LIBFREENECT2_THREADING_STDLIB - Failed
-- using tinythread as threading library
-- Found PkgConfig: /opt/local/bin/pkg-config (found version "0.28") 
-- checking for module 'libusb-1.0'
--   found libusb-1.0, version 1.0.18
-- checking for module 'opencv'
--   found opencv, version 2.4.11
-- TurboJPEG_INCLUDE_DIR = full-path-to/depends/libjpeg_turbo/include
-- Performing Test TURBOJPEG_WORKS
-- Performing Test TURBOJPEG_WORKS - Success
-- TurboJPEG_LIBRARY = full-path-to/depends/libjpeg_turbo/lib/libturbojpeg.a
-- checking for module 'glfw3'
--   found glfw3, version 3.1.2
-- Found OpenCL: /System/Library/Frameworks/OpenCL.framework  
Linking with these libraries: opencv_calib3d;opencv_contrib;opencv_core;opencv_features2d;opencv_flann;opencv_gpu;opencv_highgui;opencv_imgproc;opencv_legacy;opencv_ml;opencv_nonfree;opencv_objdetect;opencv_photo;opencv_stitching;opencv_superres;opencv_ts;opencv_video;opencv_videostab;full-path-to/depends/libjpeg_turbo/lib/libturbojpeg.a;pthread;glfw;/System/Library/Frameworks/OpenCL.framework
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LibUSB_INCLUDE_DIR
   used as include directory in directory full-path-to/examples/protonect
   used as include directory in directory full-path-to/examples/protonect
   used as include directory in directory full-path-to/examples/protonect

-- Configuring incomplete, errors occurred!
See also "full-path-to/examples/protonect/build/CMakeFiles/CMakeOutput.log".
See also "full-path-to/examples/protonect/build/CMakeFiles/CMakeError.log".

[floe]

@gaborpapp The libusb install in depends also has a pkgconfig file, so it should be picked up first, at least when the search path is in the right order. I don't really know what to make of the LibUSB error message right now, though...

[larshg]

@gaborpapp I have added include and lib to the search path for depends folder - can you try #260 ?

Maybe the pkg-config sets another variable than LibUSB_INCLUDE_DIR - can you see what name it is @gaborpapp - then we can rename the scripts accordingly. It could be LibUSB_INCLUDE_DIRS?

Edit: I can see that @goldhoorn has added a check on this exact variable with reference to buggy pkg-config file - but he only added for linux with this path: /usr/include/libusb-1.0 - so maybe we can add to the depends/libusb too.

[hanyazou]

@larshg pkg_check_modules macro provides only <XPREFIX>_INCLUDE_DIRS. (Not _DIR but _DIRS.)

[gaborpapp]

@larshg grepping CMakeCache.txt for libusb gives these lines, which seem relevant. although this is still the libusb installed on the system instead of the one in depends.

CMakeCache.txt:LIBUSB_INCLUDE_DIRS:PATH=LIBUSB_INCLUDE_DIRS-NOTFOUND
CMakeCache.txt:LibUSB_INCLUDE_DIR:PATH=LibUSB_INCLUDE_DIR-NOTFOUND
CMakeCache.txt:LibUSB-1.0_INCLUDEDIR:INTERNAL=/opt/local/include
CMakeCache.txt:LibUSB-1.0_INCLUDE_DIRS:INTERNAL=/opt/local/include/libusb-1.0

[xlz]

@larshg
So much breakage for Linux and Mac.

Can you document your workflow? Even if I want to fix your cmake files and have a Windows machine to test, I still don't know what you intended for this kind of stuff here ("libusb-win32 is a port of the USB library ​libusb-0.1", we never used libusb-0.1), and I don't know how to avoid breaking your workflow.