Thanks for the great work on this.
Are there any details, which build configurations have been tested?
I'm getting some build errors on windows vs2019 when Python is enabled, so I had to disable it in the USD (21.08) and the hdCycles builds.
Also the OpenVDB versions are causing some problems. The USD default is v6.1 and the Cycles defaulft is 8.0.1 and changing any of them to match them is generating new errors.

I am havening similar issues when trying to build it under Linux.
One of the main problems seems to be that the build prefers using the
USD, Boost, and Python versions of the Blender dependencies and not the ones used to build the external USD.

Is there any reason why hdCycles uses its own FindUSD.cmake to set up the USD dependencies instead of the cmake config which is automatically build
by USD?

Is there any reason why hdCycles uses its own FindUSD.cmake to set up the USD dependencies instead of the cmake config which is automatically build

Try setting the CMAKE_FIND_PACKAGE_PREFER_CONFIG option to sidestep that behavior.

It's probably not possible to use Blender's precompiled libraries at all, unless you build USD against Blender's precompiled libraries. So right now, it may be easiest to build without a precompiled library directory present, and setting TBB_ROOT_DIR, OPENVDB_ROOT_DIR, PYTHON_ROOT_DIR, etc. manually if needed.

We should be able to make this process smoother though, or at least document it.

Right, the build process could use some improvement. Setting USD_ROOT, TBB_ROOT(_DIR), OPENVDB_ROOT(_DIR) etc. works for the moment though (most importantly USD_ROOT and OPENVDB_ROOT, the others are used in mostly ABI compatible ways, so doesn't matter as much if linking against the different version in the precompiled libraries). Can also just disable OpenVDB support to not worry about it at all with WITH_OPENVDB=0. To get a USD build working that was built with Python, currently have to set a USD_PYTHON_LIBRARIES CMake variable with the additional libs to link (e.g. USD_PYTHON_LIBRARIES=boost_python37-vc141-mt-x64-1_68;python37 on Windows for Python 3.7).

Relying on find_package(pxr) and pxrConfig.cmake could be an option to solve this, just need to find a way to integrate this into the Blender build system without disrupting it when not building the Hydra render delegate.

I committed various fixes for Linux, and updated the standalone repository to include the Hydra render delegate. Hopefully I didn't break Windows in the process.

I did some work towards getting this building against Houdini in D14594: Cycles Hydra: support for building against Houdini.

It's not actually working yet, any help debugging this is welcome.

Awesome! There is a bit more necessary to get it running with Houdini on Windows it seems. I posted some suggestions to D14594 that made it work for me.

I added support for rendering USD files from the Cycles standalone executable in rC1a5f4932b481: Add USD as a file format for Cycles standalone rendering and rC5d03a41653e3: Build: preparation for supporting USD in standalone.

This also includes changes to make the Hydra render delegate build using the upcoming 3.2 precompiled libraries update. The resulting plugin will not be particularly useful as Blender can't load it, but being able to build the standalone executable without any additional libraries is nice.

Still rough around the edges in many ways, here's a render with a USD file exported from Blender:

I also made some changes to Houdini building to fix issues with packages in rC949e461053ab: Build: install Houdini render delegate in houdini/dso/usd_plugins.

Topic for feedback created here:
https://devtalk.blender.org/t/cycles-hydra-render-delegate-and-usd-feedback/24075