# Advice on portable USD build artifacts **URL:** \ **Category:** Build and Deployment\ **Created:** [June 17, 2024, 11:45pm UTC](https://forum.aousd.org/t/advice-on-portable-usd-build-artifacts/1607 "2024-06-17T23:45:45Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![lbiasco-sie](https://avatars.discourse-cdn.com/v4/letter/l/3e96dc/32.png) [@lbiasco-sie](https://forum.aousd.org/u/lbiasco-sie)\ **Post date:** [June 17, 2024, 11:45pm UTC](https://forum.aousd.org/t/advice-on-portable-usd-build-artifacts/1607/1 "2024-06-17T23:45:45Z")
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](https://github.com/PixarAnimationStudios/OpenUSD/issues/1025) and [here](https://github.com/PixarAnimationStudios/OpenUSD/issues/2771)). 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: ```auto 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](https://developer.nvidia.com/usd) don’t have this issue and instead use `${_IMPORT_PREFIX}` even with “external” libraries like boost: ```auto 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? ---
**Author:** ![pmolodo](https://avatars.discourse-cdn.com/v4/letter/p/2acd7d/32.png) [@pmolodo](https://forum.aousd.org/u/pmolodo)\ **Post date:** [June 18, 2024, 7:06pm UTC](https://forum.aousd.org/t/advice-on-portable-usd-build-artifacts/1607/2 "2024-06-18T19:06:18Z")
Hi - I’ve submitted two PRs to help with this issue to the OpenUSD repo: - [cmake: fix for absolute path to libm.so in pxrConfig.cmake by pmolodo · Pull Request #2796 · PixarAnimationStudios/OpenUSD · GitHub](https://github.com/PixarAnimationStudios/OpenUSD/pull/2796) - [cmake: fix absolute path to GL libraries in pxrConfig.cmake by pmolodo · Pull Request #2827 · PixarAnimationStudios/OpenUSD · GitHub](https://github.com/PixarAnimationStudios/OpenUSD/pull/2827) 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](https://github.com/AcademySoftwareFoundation/MaterialX/pull/1603), [PR1606](https://github.com/AcademySoftwareFoundation/MaterialX/pull/1606)), 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](https://github.com/PixarAnimationStudios/OpenUSD/commit/8a454b0019231762e7403c5d6fe32ad9d9d82a85), 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](https://github.com/PixarAnimationStudios/OpenUSD/pull/2796) and [PR2827](https://github.com/PixarAnimationStudios/OpenUSD/pull/2827) 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! ---
**Author:** ![pmolodo](https://avatars.discourse-cdn.com/v4/letter/p/2acd7d/32.png) [@pmolodo](https://forum.aousd.org/u/pmolodo)\ **Post date:** [June 18, 2024, 7:10pm UTC](https://forum.aousd.org/t/advice-on-portable-usd-build-artifacts/1607/3 "2024-06-18T19:10:51Z")
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](https://github.com/PixarAnimationStudios/OpenUSD/pull/2796#issuecomment-1821891838) for a function that does so, with example usage. It’s ugly, but it works for now! ---
**Author:** ![lbiasco-sie](https://avatars.discourse-cdn.com/v4/letter/l/3e96dc/32.png) [@lbiasco-sie](https://forum.aousd.org/u/lbiasco-sie)\ **Post date:** [June 18, 2024, 7:20pm UTC](https://forum.aousd.org/t/advice-on-portable-usd-build-artifacts/1607/4 "2024-06-18T19:20:14Z")
Thanks for all the great info, Paul! ---
**Author:** ![pmolodo](https://avatars.discourse-cdn.com/v4/letter/p/2acd7d/32.png) [@pmolodo](https://forum.aousd.org/u/pmolodo)\ **Post date:** [July 1, 2024, 12:45am UTC](https://forum.aousd.org/t/advice-on-portable-usd-build-artifacts/1607/5 "2024-07-01T00:45:11Z")
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!