Windows build and installation issues

[lbiasco-sie]

I've recently been trying to build HoudiniUsdBridge on Windows 10 and have run into a handful of problems. I'm building with Visual Studio 2022 (and tested 2019) for Houdini 19.5.435 (using the matching commit), and for the sake of testing I've been building against SideFX's public USD 22.05 branch for Houdini 19.5 (and tested a custom 22.08 version). There's a chance that I misconfigured something in my attempts to get this working, so feel free to callout anything that shouldn't actually be an issue.

• The Windows dependencies list needs to be updated (this is already mentioned in issue #21)

  • Remove libcurlwrap, libGP, libHUSD, libgusd
  • Add openvdb_sesi, HUSD (or specifically add it to all the dependent targets)
  • Rename hboost_system-mt -> hboost_system-mt-x64

• Some general configuration changes were also needed

  • C++17 needs to be set for a use structured bindings to compile
  • -DHUSD_EXPORTS, -DGUSD_EXPORTS need to only be set for HUSD
    • With these set for everything, a number of random, cryptic compiler errors show up (unresolved symbols, missing template functions, etc)

• Windows cannot use the custom-built version of HoudiniUsdBridge without first removing the precompiled libHUSD.dll and libgusd.dll

  • This seems to be because Houdini will inject its executable paths into PATH on startup, with no way to put the custom library's path before the precompiled
  • To work around this we can moved the precompiled libraries to a backup directory, but this prevents us from launching vanilla Houdini without some additional tuning via a script or general environment variables

The first two issues are easy to work around so whether a fix is warranted or not, they're not urgent. The last issue is a pretty significant problem, though one that may require altering how core Houdini launches so I'd assume it'd be hard to fix.

I also wanted to ask about something related: Houdini ships with libHUSD.dll and libgusd.dll, but HoudiniUsdBridge combines them to only build libHUSD.dll. Is there a particular reason for this? It would be handy to have both, as without a custom libgusd.dll, the precompiled libgusd.dll gets picked up even if the custom libHUSD.dll is found first, leading to multiple symbol definition errors.

---

P.S. I'd also like to talk about the limitations behind building HoudiniUsdBridge against alternate USD major versions and whether there's any leeway for even a super hacky, stars-aligned solution for it. With that said, I know the question has come up before so if it's a hard no, I can just focus on the above issues.