Advice on portable USD build artifacts

Community Build and Deployment
1

A coworker of mine has started looking into more robust build and deployment for USD at our studio, and a roadblock we’ve been running into is how CMake will bake absolute paths into the linking targets (examples of this behavior can be found in some open GitHub issues, like here and here). This makes it difficult to use remote machines with different file paths to build USD plugins.

For reference the resulting pxrTargets.cmake file has blocks like this:

set_target_properties(tf PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include;C:/usr/bin/python3/Include;C:/path/to/OpenUSD/Install/Release/include/boost-1_78;C:/path/to/OpenUSD/Install/Release/include"
  INTERFACE_LINK_LIBRARIES "arch;Shlwapi.lib;Python3::Python;C:/path/to/OpenUSD/Install/Release/lib/boost_python39-vc143-mt-x64-1_78.lib;C:/path/to/OpenUSD/Install/Release/lib/tbb.lib"
  INTERFACE_SYSTEM_INCLUDE_DIRECTORIES "C:/usr/bin/python3/Include;C:/path/to/OpenUSD/Install/Release/include/boost-1_78;C:/path/to/OpenUSD/Install/Release/include"
)

While trying to find a good fix or workaround for this problem, we noticed that NVIDIA’s pre-built plugins found at their USD landing page don’t have this issue and instead use ${_IMPORT_PREFIX} even with “external” libraries like boost:

set_target_properties(tf PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include;${_IMPORT_PREFIX}/include/boost-1_78"
  INTERFACE_LINK_LIBRARIES "arch;Shlwapi.lib;Python3::Python;${_IMPORT_PREFIX}/lib/boost_python310-vc142-mt-x64-1_78.lib;${_IMPORT_PREFIX}/lib/tbb.lib"
  INTERFACE_SYSTEM_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/boost-1_78;${_IMPORT_PREFIX}/include"
)

Does anybody have insight on how to configure CMake or otherwise get a result like NIVIDA’s?

2

Hi - I’ve submitted two PRs to help with this issue to the OpenUSD repo:

If you care about the topic, please post on those threads to let Pixar know you want them!

I also made two similar fixes to the MaterialX repo (PR1603, PR1606), which were merged as of 1.38.9. These absolute paths were also “transitively” making it into the OpenUSD paths… so now that OpenUSD has updated to 1.38.10, we should at least see those paths fixed with latest dev builds (though I haven’t actually checked to confirm.)

Also note that even if PR2796 and PR2827 are merged, there may still be a few straggler absolute paths left in the pxrConfig.cmake / pxrTargets.cmake - but this will at least be a big step in the right direction!

2 Likes
3

Oh - as for how the NVIDIA release gets rid of the absolute paths - alas, there’s no magic solution, we just have an ugly regex-based script which goes through and find/replaces absolute paths with ${_IMPORT_PREFIX} based ones.

In the meantime, though, you can “patch up” the absolute paths in your OWN cmake files, after doing the find_pacakge("pxr") call - see this comment for a function that does so, with example usage. It’s ugly, but it works for now!

2 Likes
4

Thanks for all the great info, Paul!

5

Just to update - Pixar just recently merged the two PRs I referenced, so between this and the update to the update to MaterialX 1.38.10, the cmake should now be more portable.

Thanks Pixar!