Added pkg-config file to support external library usages

[goldhoorn]

No description provided.

[xlz]

Looks fine. But synergy with #283 is also needed. If libfreenect2 includes libusb statically, it also needs to provide libusb's flags.

[goldhoorn]

Leben husb is not part of freenect itself. Therefore the library which includes libusb does not neet to link gainst libusb

[goldhoorn]

ops cell-phone-auto-correction (prev post)

Why we should need to link against statically against libusb in a shared library?
I see no reason to do so. Furthermore this PR blocks the integration of the kinect into rock (see linked PR) and has no influence to others.

If another (higher-level) library needs libusb, he has to make sure that the correct libusb version is taken. For us we install libusb locally and the local folder is proffered in difference to the system one. So no problem at all. If you (or others) needs special behavior this is for me not part of the library itself.

You can still influence the build by passing CMAKE_CFLAGS to the build script externally.
#283 therefore is not related to this. And only a special usecase.

[xlz]

Justification for static linking libusb is from #281:

• Distro packager wants to create a libfreenect2 package.
• libfreenect2 has to carry a copy of libusb-1.0.so, because the patched libusb-1.0 is not released anywhere.
• Carrying a duplicate of libusb-1.0.so in a package conflicts with the normal libusb-1.0 package.
• Static linking can avoid a duplicate libusb-1.0.so in the user's system. It can also avoid the RPATH mess.

In order to implement static linking, the libraries that are linked by libusb (-ludev -pthread) have to be linked by libfreenect2 now.

[goldhoorn]

However i don't want to use the static linked version of libfreenect, so this PR has no influence.
Is there a reason to not merge it right ahead?

[xlz]

Well, it is fine to merge. If you are not willing to provide such fix, we can fix it later.

[goldhoorn]

For me the current solution is sufficient 👍 for merge