Stage bundles and tools in the binary tree, never the source tree

[snkmcb]

Summary

Phase 6 of the CMake cleanup, the one #27 left out. ost 0.23.6 is now pinned, and it packages a bundle and a tool from a per-target stage, so a build no longer has to write into the checkout.

Until now, execMotion's library and generated plugInfo.json, and the three CLIs, were built into plugins/execMotion/lib/, plugins/execMotion/plugin/resources/execMotion/ and tools/*/bin/, because ost 0.23.4 packaged them from there. After this PR:

• cmake/UsdMotionStage.cmake puts each member's build output in its binary directory, in the same layout as the member itself: a tool's bin/, and a bundle's lib/ next to plugin/resources/<name>/plugInfo.json. Multi-config generators get one stage per configuration (<binary>/<config>/), so Debug and Release no longer overwrite each other. The build's own tests run against this stage.
• execMotion has install rules. They put lib/ next to the registration, at the path usd.plug_info names, so plugInfo.json's relative LibraryPath resolves in any prefix. ost plugin build installs the bundle into its per-target stage, and ost plugin test and ost plugin package read it from there. The package drops from 67 to 66 files: the one removed is plugInfo.json.in, which only the old source-tree layout picked up.
• Tools: ost build takes each executable from the member's bin/ in the root build tree. With the Ninja generator ost uses, that directory is the stage. The warning ost build used to print ("the successful root build produced no matching file") is gone.
• motion_convert's build copies the profiles into <stage>/share/usd-motion-plugins/profiles/motion. A converter run from the build tree therefore still finds them with no flags, through the same rule it uses in an installed prefix (<exe>/../share/...). The C++ changes only in comments.
• .gitignore no longer hides lib/, bin/ and plugInfo.json under plugins/ and tools/. If a build output lands in the source tree again, git status will show it. buildInfo.json is removed from the ignore list too: nothing in this repo or in ost writes one.

A checkout built before this change still has the old outputs. It can delete plugins/execMotion/lib/, plugins/execMotion/plugin/resources/execMotion/plugInfo.json and tools/*/bin/. The CHANGELOG says the same.

Type of change

• Bug fix
• Feature or behavior change
• Documentation or test change
• Build or maintenance change

Validation

Windows, ost 0.23.6 (the pinned CLI). The old source-tree outputs were deleted first, and git status showed nothing new at every step:

• ost build + ost test: 53/53. Compared with main, the ctest definitions differ only in paths: source-tree lib//bin/ became the binary-tree stage. ost filled all three tool stages from the build tree.
• ost plugin build plugins/execMotion, which now reports bundle-stage/lib and bundle-stage/plugin/...; then ost plugin test (OK), ost plugin package (matched (ost-managed)), and ost plugin test --from-package (OK).
• ost plugin package --workspace: one bundle and three tools.
• Plain CMake with the Visual Studio generator: 53/53, with the stages under <member>/Release/.
• cmake --install puts lib/libExecMotion.dll and plugin/resources/execMotion/plugInfo.json into the prefix. The three tools and execMotion were then built and tested standalone against that prefix: all pass.
• motion_convert was run with no --profile-dir and no USDMOTION_PROFILE_PATH from both build trees, and converted the recorded export successfully each time.
• check_docs.py. Regenerating the CI workflow produces no content change.

Linux and macOS are this PR's CI.

Checklist

• The change is focused and ready for review.
• I added or updated tests when behavior changed.
• I updated the owning documentation when a public fact or capability changed.
• I did not add a motion capture, clip, avatar model or screenshot without redistribution permission.
• This pull request does not contain a security report.

🤖 Generated with Claude Code