pxrTargets.cmake contains absolute build paths

[mistafunk]

Description of Issue

After make install USD, cmake/pxrTargets.cmake unexpectedly contains absolute paths. In an consuming cmake script, find_package(pxr CONFIG ...) fails with:

CMake Error in usd/CMakeLists.txt:
   Imported target "tf" includes non-existent path
    "/xxx/boost-xxx/include"
   in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:
   * The path was deleted, renamed, or moved to another location.
   * An install or uninstall procedure did not complete successfully.
   * The installation package was faulty and references files it does not provide.

"/xxx/boost-xxx/include" is an absolute path to the boost include directory on our build server which obviously does not exist anymore when consuming USD in a downstream build system.

Steps to Reproduce

1. Setup cmake to build USD static libraries:

   -DBUILD_SHARED_LIBS=0
   -DPXR_BUILD_MONOLITHIC=0
   -DPXR_ENABLE_PYTHON_SUPPORT=0
   -DPXR_BUILD_IMAGING=0
   -DPXR_BUILD_TESTS=0
   -DBOOST_ROOT=xxx
   -DBoost_DEBUG=1
   -DBoost_NO_SYSTEM_PATHS=1
   -DBoost_ADDITIONAL_VERSIONS="1.71.1;1.71.0;1.71"
   -DTBB_LIBRARY=xxx -DTBB_tbb_LIBRARY=xxx -DTBB_INCLUDE_DIR=xxx
   -DOPENEXR_LOCATION=xxx
   -DGLEW_LOCATION=xxx
   -DCMAKE_INSTALL_PREFIX=xxx
   -DCMAKE_BUILD_TYPE=Debug
   -DCMAKE_CXX_FLAGS="-D_GLIBCXX_USE_CXX11_ABI=0"
   /path/to/USD-19.11

2. ninja install
3. Try to consume the pxr target with find_package

System Information (OS, Hardware)

CentOS 7.6

Package Versions

USD 19.11

[jilliene]

Filed as internal issue #USD-5682

[moddyz]

Just hit this too 😄 definitely limits the portability of pxrTargets.cmake when attempting to consume it directly.

It seems like the absolute paths are due to the usage of target_include_directories(... PUBLIC ...).

On a local build - attempting to privatize target_include_directories resulted in a lot of the downstream libraries which were expecting to inherit required includes to fail compilation.

[JGamache-autodesk]

Had that issue very recently with MaterialX. The solution was annoyingly simple once I finally found it. All install destination paths must be relative. This will allow the CMake generator to issue relocatable code that does not contain absolute paths. All that was needed was to remove a lot of ${CMAKE_INSTALL_PATH} and it worked.

[JGamache-autodesk]

@moddyz Got the same issue when building USD with MaterialX. Any downstream application that links with the hdSt library will fail to link unless that downstream application also happens to use MaterialX. This is due to MaterialX libraries being declared PUBLIC, which adds these libraries to the list that the downstream client requires, even when not needed.

set_target_properties(hdSt PROPERTIES
  INTERFACE_LINK_LIBRARIES "hio;garch;glf;hd;hgiGL;sdr;tf;trace;hdMtlx;${PXR_USD_LOCATION}/lib/osdCPU.lib;${PXR_USD_LOCATION}/lib/osdGPU.lib;MaterialXGenShader;MaterialXRender;MaterialXCore;MaterialXFormat;MaterialXGenGlsl"
)

The MaterialX libraries should have been declared PRIVATE instead.

[carsonbrownlee]

this still seems to be an issue. A simple external fix is to run a string replace on pxrTargets.cmake to replace the absolute path with ${_IMPORT_PREFIX}. I'm not sure how to fix this in USD itself, other than perhaps JG's suggestion above.

[manuelkoester]

This still seems to be an issue, but I just wanted to leave by this workaround example from the Adobe USD-Fileformat-plugins repository here, which is using github actions to build USD.

https://github.com/adobe/USD-Fileformat-plugins/blob/main/.github/workflows/create-usd-release.yml#L158