Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mac OS X port #72

Closed
rpavlik opened this issue Apr 1, 2015 · 11 comments
Closed

Mac OS X port #72

rpavlik opened this issue Apr 1, 2015 · 11 comments

Comments

@rpavlik
Copy link
Member

rpavlik commented Apr 1, 2015

Should be fairly straightforward, since it did build on OS X in the past. I can think of exactly one change that would break the Mac build, and it will break with a friendly compiler error telling exactly what needs to be implemented. Any other breakage is unintentional.

See also:
OSVR/OSVR-Unreal#4

@rpavlik
Copy link
Member Author

rpavlik commented Oct 1, 2015

More details on this (including what would need to be done, both for OSVR-Core, and for an Oculus driver independent of their official SDK) have been posted to http://vrguy.blogspot.com/2015/09/advancing-vr-support-for-mac.html

Possible help with the usbserialenum (to get it past being stubbed-out like on Android) might be found in pyserial, since it works on mac, and at least on Windows, I can filter by VID/PID:

cc @d235j who showed some interest

@d235j
Copy link
Contributor

d235j commented Oct 1, 2015

Thanks. I have access to Rift hardware for testing and I will hopefully obtain an OSVR HDK 1.3 once it's available for order.
By the way, I did notice that the SteamVR-OSVR plugin is out of date, and doesn't even build against the latest OpenVR SDK. What are the plans with regards to this?

@rpavlik
Copy link
Member Author

rpavlik commented Oct 1, 2015

Oh rats, they broke API again?

Looking for community contribution, not sure if we have someone currently lined up to work on it internally but all work will be public to avoid duplication of effort..

Back to the OS X port - first pull request merged, thanks! Would be great to get travis ci going (in general, but also) for Mac OS X build testing, since our CI setup doesn't have a Mac in it.

@d235j
Copy link
Contributor

d235j commented Oct 1, 2015

It seems like they added some required API functions that we don't implement yet. One thing at a time for me, though :)

As for Mac support for Travis: that should be fairly straightforward and I can get to it soon. I'm already using Hombrew for dependencies including libfunctionality (and a goal down the road is to have a tap for OSVR).

@rpavlik
Copy link
Member Author

rpavlik commented Oct 1, 2015

awesome, great to hear! Probably easier to get the Mac Travis build than the Linux, then, since you have homebrew (build from source) vs. apt (please prebuild if you can).

@d235j
Copy link
Contributor

d235j commented Oct 1, 2015

Oh right, I have to upstream a fix to the jsoncpp formula first. Once that's done, Travis compile for Mac should be rather straightforward.

@godbyk
Copy link
Contributor

godbyk commented Oct 1, 2015

One more fix I had to make to vrpn to build on my Mac was to add #include <unistd.h> to vrpn_Thread.C for mktemp. This should be a cross-platform include (no #ifdef`s necessary).

@d235j
Copy link
Contributor

d235j commented Oct 1, 2015

That's already fixed in vrpn upstream — I just had to pull in the latest git release.

@rpavlik
Copy link
Member Author

rpavlik commented Oct 2, 2015

Yes, that's been pulled.

@d235j
Copy link
Contributor

d235j commented Oct 3, 2015

Next steps are to test on Windows to ensure that SDL2 is still findable and that everything builds correctly, and to set up a travis config (Homebrew pulled my jsoncpp PR).

@rpavlik
Copy link
Member Author

rpavlik commented Nov 6, 2015

I think we can mark this one as fixed and close it! Thanks, @d235j !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants