Fix openusd materialx stdlib path

[nicolaspopravka]

Fixes #451.

OpenUSD compiles the MaterialX standard-library directory from the Conan package directory into PXR_MATERIALX_STDLIB_DIR. That path no longer exists after the packages are installed into the ci-vfxall image.

Add support for per-image environment variables in generated Dockerfiles and set PXR_MTLX_STDLIB_SEARCH_PATHS to ${ASWF_INSTALL_PREFIX}/share/MaterialX/libraries in ci-vfxall/image.yaml, as a runtime workaround.

Assisted-by: OpenAI Codex / GPT-5

[jfpanisset]

The fix is clearly required, the proposed solution has a couple of issues:

• Although there are precedents in our recipes (which are in the process of being removed), using environment variables to pass parameters to the Conan build process is not the preferred way. The [buildenv] section of the packages/conan/settings/vfx202x files (which are in turn auto generated from python/aswfdocker/data/conan-profile-vfx.jinja2 and running aswfdocker dockergen) is one place to do this, but if you look at [PR Ispc from source #449] the project is moving to use the [conf] Conan mechanism to propagate these types of options to Conan recipes, in this case allowing different packages to use different clang/lvvm versions. [PR Ispc from source #449] is awaiting review by Moonray since it mostly affects that project and should be going in soon.

• More generally Conan package builds are meant to be relocatable, and should generally avoid hard coded absolute paths. The script scripts/common/install_conanpackages.sh uses conan install to install packages (and all their transitive dependencies) into package specific directories, and a post processing step tries to clean up any hard coded Conan build paths before using rsync to deploy all packages into /usr/local/ (although in theory the script can be called with a different target location if someone wanted to build a container image in /opt/something for instance). In the context of OpenUSD, I used to have to Conan build paths hard coded into the shebangs of all of the Python scripts, fortunately for the latest set of releases I was pointed to using PXR_PYTHON_SHEBANG to set those to /usr/bin/env python3 thus making those scripts relocatable.

Unfortunately in this case in pxr/usd/usdMtlx/CMakeLists.txt:

add_definitions(-DPXR_MATERIALX_STDLIB_DIR="${MATERIALX_STDLIB_DIR}")

which in third_party/renderman/plugin/hdPrman/hdMtlx.cpp gets compiled into:

static mx::FileSearchPath
_ComputeSearchPaths()
{
    mx::FileSearchPath searchPaths;
    static const SdrStringVec searchPathStrings = UsdMtlxSearchPaths();
    for (auto path : searchPathStrings) {
        searchPaths.append(mx::FilePath(path));
    }
#ifdef PXR_DCC_LOCATION_ENV_VAR
    const std::string dccLocationEnvVar(PXR_DCC_LOCATION_ENV_VAR);
    const std::string dccLocation = mx::getEnviron(dccLocationEnvVar);
    searchPaths.append(mx::FilePath(dccLocation + PXR_MATERIALX_STDLIB_DIR));
    searchPaths.append(mx::FilePath(dccLocation + PXR_MATERIALX_BASE_DIR));
#endif
    return searchPaths;
}

install_conanpackages.sh could try to patch the binary (which in theory would work as long as the Conan build path is longer than the desired /usr/local/ path) but that would be gross. For the other reference in pxr/usd/usdMtlx/utils.cpp:

static const SdrStringVec
_ComputeStdlibSearchPaths()
{
    // Get the MaterialX/libraries path(s)
    // This is used to indicate the location of the MaterialX/libraries folder
    // if moved/changed from the path initialized in PXR_MATERIALX_STDLIB_DIR.
    SdrStringVec stdlibSearchPaths =
        _GetSearchPathsFromEnvVar("PXR_MTLX_STDLIB_SEARCH_PATHS");

    // Add path to the MaterialX standard library discovered at build time.
#ifdef PXR_MATERIALX_STDLIB_DIR
    stdlibSearchPaths =
        _MergeSearchPaths(stdlibSearchPaths, { PXR_MATERIALX_STDLIB_DIR });
#endif

Would it make sense for the ci-vfxall build container to set / append the /usr/local/ install path for the MaterialX stdlib to the PXR_MTLX_STDLIB_SEARCH_PATHS environment variable?

These images should be as useful as possible, so this change could be merged as is, with perhaps a FIXME addition to the comment to indicate that the full fix might require patching OpenUSD itself for better relocatable build support.

[nicolaspopravka]

I have adopted your suggestion and updated the PR to set PXR_MTLX_STDLIB_SEARCH_PATHS=${ASWF_INSTALL_PREFIX}/share/MaterialX/libraries in ci-vfxall. The Conan recipe change has been removed. We no longer pass ASWF_INSTALL_PREFIX into the build. The generated Dockerfiles and generator tests pass. Are you ok with this version ?

[jfpanisset]

The ability to add arbitrary ENV environment variables to container images is generally useful and a good workaround to the issue of the openusd package baking in the Conan build path to the MaterialX library.

Have you been able to verify that this works for the current ci-vfxall:2027 image by injecting the env var from the command line:

docker run -e PXR_MTLX_STDLIB_SEARCH_PATHS=/usr/local/share/MaterialX/libraries -it --rm aswf/ci-vfxall:2027 /bin/bash

[jfpanisset]

It looks like the DCO check is failing, all (most?) ASWF projects require commits to be signed with git commit -s.

You can follow the instructions here to retroactively sign your commits:

https://github.com/AcademySoftwareFoundation/aswf-docker/pull/452/checks?check_run_id=89726303728

[nicolaspopravka]

Yes. I verified this against the published aswf/ci-vfxall:2027 image with PXR_MTLX_STDLIB_SEARCH_PATHS=/usr/local/share/MaterialX/libraries. I also squashed out the Conan-recipe approach and force-pushed a single commit. DCO is now passing.