You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This directory contains a `pyproject.toml` based wheel build flow.
4
+
5
+
The OpenUSD build is created with `build_scripts/build_usd.py`, and a PEP 517 backend stages files from that install tree into a wheel.
6
+
In order to provide robust wheels with proper isolation, ownership of libraries, and dependency links, the wheels are modified.
7
+
This approach was chosen over installing all wheels to a common namespace because of fragility with uninstallation, upgrades, versions, and layout conflicts.
8
+
The cmake build was not extended to support a wheel native build, so the wheels needs to be fixed up by the backend.
9
+
The RPATHs are corrected for the installed layout of the wheels, and platform repair steps still use `auditwheel`, `delocate`, and
10
+
`build_scripts/pypi/updatePluginfos.py`.
11
+
12
+
The backend is designed to be extensible and support more package definitions.
13
+
14
+
15
+
## Packages
16
+
17
+
The number and content of the packages is easily configurable, the following separation is the current implementation:
18
+
19
+
-`packaging/usd-core`
20
+
-`packaging/usd-imaging`
21
+
-`packaging/usd-tools`
22
+
-`packaging/usdview`
23
+
24
+
Each package owns its corresponding shared libraries, bindings, python modules, resources, and metadata.
25
+
26
+
These packages are staged from an installed OpenUSD tree using explicit manifest globs.
27
+
The file ownership boundaries are intentionally easy to revise during review.
28
+
29
+
On Linux, native shared-library ownership now follows the package dependency graph during repair:
30
+
31
+
-`usd-core` repairs as a self-contained base wheel
32
+
- higher-level wheels exclude libraries already exported by their OpenUSD
33
+
dependencies
34
+
- the backend patches ELF `NEEDED` entries and RPATHs so later wheels resolve
35
+
back into sibling dependency `*.libs` directories after install
36
+
37
+
That keeps `usd-imaging`, `usd-tools`, and `usdview` from vendoring duplicate
38
+
copies of the same OpenUSD shared libraries.
39
+
40
+
For command-line tools, the wheel keeps the real executable under
41
+
`site-packages` and exposes the usual command name through a generated Python
42
+
launcher. That avoids relying on `pip` to preserve executable-to-library
43
+
relative paths when it installs scripts into the environment's `bin/`
44
+
directory.
45
+
46
+
## Local Build Entry Point
47
+
48
+
The backend supports two build modes:
49
+
50
+
- Build OpenUSD directly by invoking `build_scripts/build_usd.py`.
51
+
- Reuse a prebuilt install tree by setting `OPENUSD_PREBUILT_INSTALL_ROOT`.
52
+
53
+
The second mode is intended for CI integration where the install tree is
54
+
already produced elsewhere in the workflow.
55
+
56
+
## Helper Script
57
+
58
+
`packaging/build_wheels.sh` is a convenience entry point for local development.
59
+
It will:
60
+
61
+
- create a virtual environment,
62
+
- install the packaging prerequisites,
63
+
- build one shared OpenUSD install tree unless `--reuse-install` is set,
64
+
- build one or more wheels into a chosen output directory.
The helper installs the wheel-building tools it needs, and any necessary pip
76
+
packages for OpenUSD. That currently includes `Jinja2` when `usd-tools` is
77
+
requested so the schema-generation tools such as `usdGenSchema` and
78
+
`usdInitSchema` are built, and the Qt-for-Python dependencies needed for
79
+
`usdview`.
80
+
81
+
On Linux, the repair step uses `auditwheel` and requires `patchelf`. The helper
82
+
installs both into the packaging virtual environment when repair is enabled.
83
+
84
+
## Alternatives
85
+
86
+
### Common namespace packages
87
+
88
+
There are a subset of the OpenUSD libraries on pypi as individual packages (pxr-ar, pxr-sdf, etc.).
89
+
These all install into a common site-packages/pxr/.libs tree, eliminating the need for wheel repair.
90
+
There are downsides, though. Ownership of the files is not managed, uninstallation/upgrade of the packages is brittle,
91
+
and there are collision risks.
92
+
93
+
Because additional wheel build configuration is needed anyways to support the CLI tools because RPATHs will be broken due to default install layouts,
94
+
this approach was not used here.
95
+
96
+
### Single Runtime Package
97
+
98
+
Similar pypi projects sometimes use a single runtime package with all native code in it, and packages built on top of it are pure python/resources/metadata.
0 commit comments