rename examples/protonect to src

[floe]

This should probably be the very last PR to be merged for 0.1; alternative suggestions for the folder name welcome.

[HenningJ]

Shouldn't protonect itself stay in examples? It's not really part of libfreenect2, but rather an example for it. :-)

[christiankerl]

why not just put it in the root folder (as libfreenect)? src/src seems strange?!

[floe]

@HenningJ @christiankerl good points, amended.

[HenningJ]

Two more things (taken from issue #287):

• remove include/libfreenect2.h ? Since it's not actually relevant/used anywhere, it only adds confusion.
• separate the public API from the implementation by moving the headers to a different folder. That's a bit more complicated (but it would be nice for the 0.1 release), because it's not clearly separated yet. libfreenect2.hpp and frame_listener.hpp are the API, but you'd also need the PacketPipelines. And oy crouse the registration should be part of the API as well.

Also in PR #294 @laborer2008 proposes a slightly different structure. That would provide even better separation, like moving generate_resources.cpp to tools/ and test_opengl_depth_packet_processor.cppto tests/, making it even clearer, which files are actually part of libfreenect2 and which files are built around it to support it. Just some food for thought.

[xlz]

libfreenect2/libfreenect2 still seems strange.

I would like to move examples/protonect into the root directory like this:

cmake_modules/
include/libfreenect2/
src/
data/
    11to16.bin
    xTable.bin
    zTable.bin
tools/
    generate_resources.cpp
tests/
    test_opengl_depth_packet_processor.cpp
    Protonect.cpp (this is also used as a basic test case)
CMakeLists.txt
freenect2.cmake.in
freenect2.pc.in

By the way, in README.md please also change the build instructions to mkdir build && cd build && cmake .. which is the norm of using CMake that does not pollute the source directory. (I thought everyone knows this, but it seems otherwise from many bug reports.)

[kohrt]

+1 @xlz (especially the build folder part)
But Protonect could also go into tools, if you look at it as a viewer, or in examples as an example on how to use libfreenect2.

[xlz]

@wiedemeyer I don't mind either way.

@laborer2008 Now that tests and tools are moved out of src, you may be interested in reviving the attempt in #295 of using glob to list source files instead of explicitly listing them in CMakeLists.txt.

A potential approach of modularization would move non-core modules into their subdirectories in src/:

src/opengl/
    shader/
    flextGL.c
    flextGL.h
    opengl_depth_packet_processor.cpp
src/opencl/
    opencl_depth_packet_processor.cl
    opencl_depth_packet_processor.cpp

In the future:
src/cuda/
src/vaapi/
src/tegra/

Each module could carry their own CMakeLists.txt, and then the root CMakeLists.txt could automatically adds all subdirectories. I realize more refactoring is required for complete modularization. I may open a new PR for this in the future.

[laborer2008]

@xlz, Yes, of course. I see you understand my idea completely. But I myself would prefer to wait till this changeset is merged and those CMakeLists.txt someone create. Don't want to mess things here up.

Also I want to notice:

• include/freenect2 looks for me better than include/libfreenect2, especially on Windows. Even if library is called "libfreenect2". Just look on the other opensource libraries.
• Paths like src/opencl/depth_packet_processor.cl look for me better than src/opencl/opencl_depth_packet_processor.cl
• Shouldn't Protonect.cpp be called protonect.cpp as other files? If someone wants 'Protonect.exe' for executable on Windows (because it's conventional) it can be done in CMakeLists.txt

[xlz]

@laborer2008 These cosmetic name changes are likely to break things. I want to avoid them.

[floe]

@xlz I think your initial suggestion is the most sensible one which requires the least amount of renames/edits. I'll close this one and create a new PR, tracking all these renames across the other PRs would be somewhat difficult.