Copy DLLs for Protonect on Windows

[xlz]

This PR will stay idle unless any Windows users feel interested again.

Install Protonect.exe and linked DLLs to bin/, so the users can directly run Protonect.exe without having to set up environment paths or copying DLLs themselves.

Also, only include the core and highgui components of OpenCV.

[larshg]

Can you add a check if the dlls are actually found? - I, for the fun of it (before this patch - I'm not trying to find errors just for fun!), compiled glfw as a static library without a dll, so I get an error when running the install project :)

Also, do you know the instructions for copying the dll, when debugging in VS - maybe a post build script? or can we change so the library dll also gets outputted in the bin/buildtype folder like the protonect?

[HenningJ]

Locally, I just changed everything to build static libs (libusb, freenect2), then I can just link them and don't need to copy any DLLs and can more easily debug everything

[xlz]

Can you add a check if the dlls are actually found

Yes

instructions for copying the dll

What do you mean? This is merely a helper to provide convenience for testing, as least for me who is not using VS IDE. The users can of course use what VS provides and ignore this installation.

Personally I don't see the value of the build/{Win32,x86,x64}/{Release,Debug} hierarchy outweighing the complexity it brings to our build system. But I will try to avoid breaking VS workflow. If you have any trouble in VS report it.

changed everything to build static libs

I tried this and it didn't work without making a mess in CMakeLists.txt. If you have a clean patch to enable static linking of Protonect, submit it and that'd be great.

[xlz]

I think the current build system only supports building a dynamically linked Protonect.exe, therefore it is justified to enhance that functionality.

Supporting a static build of Protonect.exe is a separate matter and should be handled in a different PR.

[larshg]

If I want to debug protonect/libfreenect2(dll) I have to copy the new dll from lib folder to bin folder for VS to pick up new changes etc.

This was also a problem before this patch, so there is nothing breaking :) It would just be convenient for VS users not to copy it manually. But I can try figure it out and make a separate PR.

[xlz]

Please do, as I have no idea how to debug in VS IDE.

So, this patch is considered correct if you double click .\bin\Protonect.exe after cmake --build . --config Release --target install and it works. Is this true?

[xlz]

@HenningJ I found out how.

The problem with static linking is because the official glfw3.lib static binary is linked with MSVCRT.lib, the dynamic link version. MSVCRT conflicts with LIBCMT etc.

For static linking, the users must build glfw3 with cmake -DUSE_MSVC_RUNTIME_LIBRARY_DLL=OFF. The official binary package is not usable for static linking.

[xlz]

I'll create a seperate PR for static linking on Windows.

[xlz]

@HenningJ I built a completely static Protonect.exe, but it runs very slow with OpenGL processor. What can be the problem?

[gaborpapp]

@xlz Maybe it is a debug build? Those are quite slow in windows. Static linking should not affect performance as far as I know.

[xlz]

@gaborpapp Thanks for the note. It was because glfw3 was not found and cpu processor as used instead.

Now that glfw3.lib is included in the static Protonect.exe, the output becomes black. Anyone has the same issue? Apparently graphics driver issue - solved.

[HenningJ]

For static linking, the users must build glfw3 with cmake -DUSE_MSVC_RUNTIME_LIBRARY_DLL=OFF. The official binary package is not usable for static linking.

Really? I just got the current version from github, cmaked and built it and it was fine.

So, you're doing a pull request for static linking? That's good, so I don't have to figure out how to clean up my cmake files for a proper PR. :-)

[xlz]

Without that flag, the static glfw3.lib is compiled with /MD. It will surely conflict with other static libraries that are compiled with /MT, no?

[HenningJ]

Ah, I see what you mean now. But actually, all my static libs seem to be compiled with /MD. I believe this is the default, no?

[xlz]

At least OpenCV's pre-built static libraries are compiled with /MT. I think TurboJPEG is also the case. I have not been compiling OpenCV and TurboJPEG myself.

[HenningJ]

The more I look into it, the more confused I get.
I was linking against the DLL version of TurboJPEG, but I don't know where it took the DLL from. It's not in the same folder as the .exe, nor anywhere in my path.
When I use the static version of TurboJPEG, I still don't get any errors, but I do get related warnings:

LINK : warning LNK4098: Standardbibliothek "MSVCRT" steht in Konflikt mit anderen Bibliotheken; /NODEFAULTLIB:Bibliothek verwenden.
LINK : warning LNK4098: Standardbibliothek "LIBCMT" steht in Konflikt mit anderen Bibliotheken; /NODEFAULTLIB:Bibliothek verwenden.

But it still works fine. So I'm comfortable with ignoring these warnings.

[xlz]

#284 (building a static Protonect.exe) was closed in favor of this, because juggling /MD and /MT is just confusing.

But this PR will stay idle unless any Windows users feel interested again.

[xlz]

Implemented again in #429. This time it should work for both debugging and installation.