Package Details: oculus-rift-sdk-jherico-git 185.cbf6f96-2

Git Clone URL: (read-only, click to copy)
Package Base: oculus-rift-sdk-jherico-git
Description: Oculus SDK community version. SHIM + shared release/debug (,, OculusConfigUtil, /etc/xdg/autostart/ovrd.desktop. Use /usr/include/ovr- as path to the SDK.
Upstream URL:
Licenses: custom
Provides: oculus-rift-sdk=
Submitter: haagch
Maintainer: lubosz
Last Packager: lubosz
Votes: 7
Popularity: 0.000000
First Submitted: 2014-09-02 00:43
Last Updated: 2016-06-02 15:35

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

feilen commented on 2014-11-09 20:53

That sounds good! You could pretty easily just provide symlinks and remove build-process files. /opt sounds good for the SDK overall.

haagch commented on 2014-11-09 10:26

After sleeping over it, I thought people can depend on *any* part of the SDK including the tuscany assets and whatnot so it probably is best to install the whole thing. I don't really like putting 114 megabyte in /usr/include, so maybe I'll put it into /opt or /usr/share or so later and only put all the .h files into /usr/include.

feilen commented on 2014-11-08 20:57

Alrighty. Well, for Minecrift, the best solution would be to copy the entire directory to /usr/include/<name> so that anyone with OCULUS_SDK or something similar defined will simply have to point it to that. Minecrift needs all of /Src, /Include and /Samples to build, but Dolphin just needs /Src and /Include.

Not totally sure how to procede, but since you're copying /Include into /ovr anyway, why not just leave it as /Include?

haagch commented on 2014-11-08 20:17

The pkg-config file is not official, just something I put together quickly, so you might want to think about whether you really want to depend on it.

feilen commented on 2014-11-08 20:08

Ah, that seems useful. I'll work that into the neccesary makefiles I guess. Unfortunately, Minecrift (which I'm messing with now) depends on some of the sample code in Samples/. Though minecrift isn't something you'd ever need to compile from source for without actually wanting to develop for it, so that's an edge case.

haagch commented on 2014-11-08 17:06

Indeed I did not quite understand how it is supposed to be arranged. When using pkg-config --cflags libovr it will just spit out all the possible paths that could be used for including files.

I'm not sure what the alternative is. Install all SDK files to /opt or /usr/share?

feilen commented on 2014-11-08 16:50

I'm not so sure about moving the SDK into /usr/include/ovr-# in a way that changes the directory structure (moving Include and Src around)

Most development environments expect the Oculus SDK to be arranged the way it is in upstream, and only allow you to change the base location of the SDK.

feilen commented on 2014-10-28 06:00

Awesome, thanks for the fast fix!

Was there something wrong with plugdev? You might want to add in a postinstall file something which tells you after installing to add yourself to that group.

haagch commented on 2014-10-27 22:54

Hm, the SHARED keyword had been removed from the CMakeLists.txt.

I am not sure whether this even works with shared libraries but I got a bit frustrated so I decided, why not build shared and static and let the developer decide.

I did remove the hack and put it in optdepends as well as oculus-udev in case people want to do it their way.

feilen commented on 2014-10-27 22:32

The Libudev link is handled by most people by using the AUR package '', which is literally just a symlink.

After it finishes building with the current pkgbuild, I get the following message: 'install: cannot stat ‘output/’: No such file or directory'

I guess the latest SDK doesn't include that?