Document dependencies required to build

[hakanai]

Hi. I thought I'd try to get this building on AppVeyor, but I'm missing the dependencies not already covered by NuGet.

As far as I can tell, there are four things I have to fetch:

• E:\PlayspaceMover\third-party\glm-0.9.9-a2
• E:\PlayspaceMover\third-party\OculusSDK
• E:\PlayspaceMover\third-party\openvr
• E:\PlayspaceMover\third-party\VRInputEmulator

glm has the version on it so that one I might have a hope of finding. GLM themselves use AppVeyor though, so maybe it's easier to get it from NuGet?

For the other three, I'd like to know where to get the right version if it can't just be committed to source control. For openvr I can pull from GitHub but I think I'd still have to know the right commit to pull. Some of these three also have nuget packages which can supposedly be used for compile purposes but it totally depends on which version should be used.

[naelstrof]

You need Boost, OpenVR, VR Input Emulator, and GLM 0.9.9-a2. The Oculus SDK isn't actually needed, it's in the build because I was experimenting with it. Sorry!

As for versions, the only version that matters is GLM, since quaternion lookat stuff was only introduced really recently. Everything else you can just use the newest versions since they all have backward compatibility.

This means that you can install Boost (and boost's compiled vc-141 stuff) from nuget. OpenVR, and GLM can just be downloaded from git. While vr input emulator needs to be compiled, so you'll have to download and compile that from git.

Contact me on Discord (naelstrof#7705) or here if you have any more issues!

[hakanai]

Just to give some kind of update... I moved on to trying to get VRInputEmulator to build, and it has some dependencies on Leap Motion SDK which are breaking its build. I filed with them to ask what I was supposed to do about that, but the answer is taking some time to come back. Downloading it myself doesn't really work, because it would make it impossible to automate unless I then distributed the SDK, which may be against the rules of the licence.

[naelstrof]

Hmm, make sure you're only compiling the vrinputemulator lib, not the driver, or the installer. I only had to install boost to get it to compile correctly for me I think.

[hakanai]

Boost is luckily sitting on the appveyor build environment already, as was Qt. It doesn't have the absolute latest versions, but it has the ones VRInputEmulator's build said it wanted, so I was basically trying to get the rest of their build working on appveyor unmodified if it was possible. I think I made one change, which was allowing a build property to specify the location of boost. But I can't remember right now whether that was in their build, or in this build...

So I guess I could limit their build to build just the projects one by one except for the broken one. That way they might still accept my PR and perhaps move towards making their builds more accessible themselves. :)

[hakanai]

https://ci.appveyor.com/project/trejkaz/vrplayspacemover/build/1.0.68/job/6jk5h9mm6l8nvtya

LINK : fatal error LNK1104: cannot open file 'libvrinputemulator-d.lib' [C:\projects\vrplayspacemover\PlayspaceMover\PlayspaceMover.vcxproj]

I inspected the other build and saw no files with this name produced by the build.

[naelstrof]

That's just the debug build of vrinputemulator. You'll just have to rename it. I should totally include build instructions...

[hakanai]

Okay... so in my case, I have packaged both the debug and the release builds of VRInputEmulator identically in the zip, as whatever filenames everything came out as...

So now I get to choose, do I rename before it goes into the zip, or do I rename after it comes out of the zip, or do I come up with a completely different way to have two of the same lib in the directory if necessary (which in the CI build never occurs, but obviously occurs on dev machines.)

[naelstrof]

Once you build vrinputemulator, just rename the resulting binary (vrinputemulator.lib) to vrinputemulator-d.lib. Then use that for the debug build.

[hakanai]

Yeah, but there is a separation here. I build VRInputEmulator over in here: https://ci.appveyor.com/project/trejkaz/openvr-inputemulator/

It builds Debug and Release using the same build logic for both, so the zip files come out the same.

Likewise, my build for VRPlayspaceMover is the same for both right now, but I could try to add a conditional so that if it's the debug build, rename one file after unpacking the zip.

[naelstrof]

Oh I see, do you want me to just remove the -d in the linker names?

[hakanai]

I'm thinking I might restructure to put it in VRInputEmulator/(Debug|Release)/lib/x64. That also means that it's closer to the actual location it puts them in its own build. I'll have to update the fork I have for their side to change how I'm putting it into the zip too.

So the debug build should be resolvable, but then I noticed the release build was failing too, even though the path was already correct for that one.

"C:\projects\vrplayspacemover\PlayspaceMover.sln" (default target) (1) ->
"C:\projects\vrplayspacemover\PlayspaceMover\PlayspaceMover.vcxproj" (default target) (2) ->
(Link target) -> 
  LINK : fatal error C1047: The object or library file 'C:\projects\vrplayspacemover\PlayspaceMover\third-party\VRInputEmulator\lib\x64\libvrinputemulator.lib' was created with an older compiler than other objects; rebuild old objects and libraries [C:\projects\vrplayspacemover\PlayspaceMover\PlayspaceMover.vcxproj]
  LINK : fatal error LNK1257: code generation failed [C:\projects\vrplayspacemover\PlayspaceMover\PlayspaceMover.vcxproj]
    1 Warning(s)
    2 Error(s)

This I'm really not sure about. It makes it sound like I have to build VRInputEmulator using MSVC 2017, but it doesn't seem to build using 2017 (links taken out because I have messed with the recent builds since).

[naelstrof]

I added build documentation, I'll close this issue after a while. Or when you're happy with it.

[hakanai]

I'll call it closed. It didn't help my particular situation since I can't use any GUIs on a build server, and there is some obscure linker / compiler problem currently breaking my build over there as well, which is way too hard for me to figure out, so I've essentially given up.

(Not that it's this project which was breaking, though. It was entirely VR Input Emulator. They should just ship some working binaries that won't break the linker.)

[hakanai]

In case it's interesting, I'll leave my current progress alive at https://github.com/trejkaz/VRPlayspaceMover/tree/appveyor

I think I had just given up on using a binary VR Input Emulator for the other build, and had moved onto trying to get it to build from inside the VR Playspace Mover build. (I had also submitted a PR to that project to allow customising more locations for libraries so that I could use the openvr from this project as the one to build that project against, in case that mattered, and it might also avoid needing to install boost yet again.)

But over on the VR Input Emulator build, when I tried to use MSVC 2017, it didn't build. So my prediction was that it would fail here as well, so I stopped my attempt half way and figured I'd wake up again when they fix their build to work on 2017.

I think that overall I didn't really quit out of frustration even, it was just taking a little too much time to get a stable build going and I had other, larger problems to solve with other projects elsewhere. So it was kind of a hard decision to make. The only thing I was planning to add was an option to simulate only one fake tracker instead of 3, because I thought maybe with only 1 it would avoid the crazy leg behaviour you get when simulating 3. :)

[naelstrof]

Add the feature request as an issue and I'll implement it. One tracker doesn't make the body follow you, but has the potential to give you better basic IK.

[hakanai]

Oh, rats... I did hope the body would still follow, but I guess if it doesn't I'm just out of luck then.