Using alternative PacketPipeline when linking to Libfreenect2

[jeppewalther]

When initiating the Freenect2Device in my external code base i have up until now done.

libfreenect2::Freenect2Device *dev = freenect2.openDefaultDevice();

However now i want to use OpenCL

libfreenect2::Freenect2Device *dev = freenect2.openDefaultDevice(new OpenCLPacketPipeline);

This is not possible unless i include packet_pipeline.h. And i don´t really want to do that as it results in include hell.

I instead suggest a initiation based on an enum defined in libfreenect2.hpp

Or maybe there is a better solution ?

[christiankerl]

What do you exactly mean by include hell? We could move the packet pipelines to individual headers or pimpl them...

[jeppewalther]

I am missing libusb.h. Which are from the dependencies, so i really don't want to include them in my own application.

[jeppewalther]

You are right moving them to separate headers are probably a better idea.

[christiankerl]

could you try PR #98 it should remove the dependency on libusb.h

[kohrt]

If I change the pipeline to OpenCL I get errors because the pipeline implementation is not defined in the header due to the #ifdef.... This could be fixed by adding the following lines to the end of freenect2.cmake.in:

IF("@ENABLE_OPENCL@" AND "@OPENCL_FOUND@")
    SET(freenect2_DEFINITIONS "${freenect2_DEFINITIONS} -DWITH_OPENCL_SUPPORT")
ENDIF("@ENABLE_OPENCL@" AND "@OPENCL_FOUND@")

[christiankerl]

@wiedemeyer I guess the definition of these macros should go into a header file generated during compilation. other candidates are the FREENECT2_API, PACK and threading related macros.

edit: just created an issue #100

[kohrt]

@christiankerl that is a good solution. My one was more like a quick work around to get the kinect2 bridge running with the upstream. I also used the pull-request mentioned above and I had to add install commands for the deps. But now everything works fine.