ryanstew
commented
9 years ago There's also option C: use std::dynamic_lib to directly load and call into the shared library rather than doing a build-time #[link]. The SDK now works this way: linking against the SDK means linking against a small stub library that manages a pointer table to the shared library via GetProcAddress/dlsym. Probably not worth linking against this stub library when this is quite easy to replicate in pure Rust.
Besides, because the Oculus SDK build system won't build under MinGW, static linking is out of reach on Windows. (I'll admit I haven't tried to build the new stub lib under MinGW). Adding a dependency on a DLL-based stub will be a pain for deployment.
We could instead #[link] against the real, shared DLL rather than the stub, by depending on the non-stub build from OculusSDK. In most cases, though, I don't expect users to deploy their own version of the library, so building the whole SDK is overkill.
DynamicLibrary seems most in-line with Oculus' intent for runtime deployment going forward.
The move to an official shared-DLL support model leaves two options:
Building against the source removes an installation dependency for dev. But given Oculus' intended deployment model, there's no other real advantage to building against a private copy of the SDK.