Fixes for MSVC 2013#163
Conversation
Added external/msvc-support for lack of C99-compliance workarounds. Changes to test_tracker to support MSVC because it cannot create dynamically-sized arrays. Defined _USE_MATH_DEFINES in CMakeLists for MSVC. Fixes lack of math constants when importing math.h in MSVC. Add gettimeofday for MSVC. Taken from http://stackoverflow.com/a/26085827/1256069 , implied no license. Further small changes to support MSVC. Added instructions for MSVC. Moved MSVC implementation of usleep into unistd for easier use in other targets. Replaced __func__ with __FUNCTION__ for universal platform support. Replaced sleep with usleep for cross-platform support in psmovepair. Clarified some instructions in README.msvc. Also fixed MSVC building of OpenCV. Huge change to CMakeLists. More logical sectioning. Support for MSVC, and using PS3EYEDriver in Windows. Moved sprintf fix to msvc-support/unistd.h. Made small tweaks to example programs to make them MSVC-compatible. Now everything builds successfully in MSVC. Changed OSX's libusb path back. I tried but failed to build more recent versions. Added registry file necessary for Windows PS3EYEDriver support. Added README for MinGW 64. Renamed README files to make their use-cases more obvious. Fixed regression in CMakeLists regarding libusb's include directory. Only applied to MinGW builds.
|
Squashed and rebased to fix conflicts. |
There was a problem hiding this comment.
Remove this line instead of commenting it out.
|
Additional comments:
I'm still not sure whether we really need the whole pthreads-win32 library, just http://www.slideshare.net/abufayez/pthreads-vs-win32-threads |
|
Thanks for the link about win32 threads. I'll look into it to see if it's an easy replacement and if so then I can get rid of pthreads-win32. Some changes I've made in one of my own branches have eliminated the need for ps3eye_settings.reg entirely. The PS3EYE settings are saved to a file in the home directory then restored from there, just like in Linux. I wonder though if this mechanism is even necessary (note OSX does not do it at all). From what I can tell, all that's being done is the original settings are being queried from the camera as soon as the camera is opened, the camera settings are manipulated by the API, then the original settings are restored to the camera before it is closed. In Windows, using the PS3EYEDriver, the 'original' settings are just the PS3EYEDriver defaults. There's no need to store these to a file. I propose we change these Win functions to no-ops, just like the Mac functions. Does it happen in Linux that if you change the camera settings with application A then those changed settings will be preserved when opening the camera with application B? If not, then these functions don't need to exist at all. |
|
Any news on this front? |
|
Sorry, I've had a backlog of other things. I can get back to this by the end of the week. Let me know if there's anything urgent and I can do a separate smaller pull request. |
|
I started over again in #182 . |
2 participants
Here is a cleaner version of my changes to support MSVC 2013.
While everything builds fine, not of the programs really work without merging the changes from #149 and #162 If those are merged then all programs work, including utilities and examples.
I made a lot of changes to CMakeLists.txt
IMO, it's more organized now. It's probably (almost) possible to separate the tracker portions into a separate file, if that's desirable.