Skip to content

Scope third-party install rules out of the wheel via CMake components#184873

Open
zklaus wants to merge 1 commit into
gh/zklaus/60/basefrom
gh/zklaus/60/head
Open

Scope third-party install rules out of the wheel via CMake components#184873
zklaus wants to merge 1 commit into
gh/zklaus/60/basefrom
gh/zklaus/60/head

Conversation

@zklaus
Copy link
Copy Markdown
Collaborator

@zklaus zklaus commented May 22, 2026

Stack from ghstack (oldest at bottom):

Move all install() rules onto named components so scikit-build-core
can restrict the wheel to the subset that actually belongs there.
The default component is "libtorch" (shared libraries, headers,
runtime data); explicit "torch" tags cover Python-side artifacts
(libtorch_python, the _C extension, version.py, type stubs, yaml /
jinja templates, torchgen packaged inputs, etc.); the existing "dev"
tag for find_package(Torch) configs is kept; and a new "third_party"
sentinel absorbs install rules from vendored subprojects so they
become no-ops at install time.

cmake/InstallComponents.cmake defines two helpers used at every
vendored subproject site:

pytorch_add_thirdparty_subdirectory() wraps add_subdirectory()
and temporarily overrides CMAKE_INSTALL_DEFAULT_COMPONENT_NAME
to "third_party" so the subproject's untagged install() rules
land in the suppressed component.

pytorch_install_thirdparty_headers() mirrors the subset of a
subproject's public headers that the wheel actually needs
(since we just suppressed the upstream install()), tagged with
"libtorch". This keeps libfbgemm.a, libkineto.a, libcpuinfo.a,
libtorch_xpu_ops.a, and the corresponding lib64/cmake/* configs
out of the wheel while preserving the include surface that
torch's public headers and downstream cpp_extension consumers
depend on.

Each add_subdirectory(third_party/...) site is rewritten to use the
wrap macro and, where the subproject contributes public headers, an
immediately-following pytorch_install_thirdparty_headers() (or, for
sleef's generated sleef.h and torch-xpu-ops' sycltla .so libraries,
an explicit install() rule). pyproject.toml selects the wheel
contents via install.components = ["libtorch", "torch", "dev"].

Co-Generated with Claude Code

cc @gujinghui @PenghuiCheng @XiaobingSuper @jianyuh @jgong5 @mingfeima @sanchitintel @ashokei @jingxu10 @min-jean-cho @yanbing-j @Guobing-Chen @Xia-Weiwen @snadampal

[ghstack-poisoned]
@pytorch-bot
Copy link
Copy Markdown

pytorch-bot Bot commented May 22, 2026

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/184873

Note: Links to docs will display an error until the docs builds have been completed.

❌ 4 New Failures, 1 Pending, 12 Unrelated Failures, 1 Unclassified Failure

As of commit a29741f with merge base 04d232f (image):

NEW FAILURES - The following jobs have failed:

UNCLASSIFIED FAILURE - DrCI could not classify the following job because the workflow did not run on the merge base. The failure may be pre-existing on trunk or introduced by this PR:

  • Check mergeability of ghstack PR / ghstack-mergeability-check (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
    RuntimeError: PR 180243 is out of sync with the corresponding revision ede170a73635e5dff9349ab052e758cea7ffdca0 on branch gh/zklaus/49/orig that would be merged into main. This usually happens because there is a non ghstack change in the PR. Please sync them and try again (ex. make the changes on origin/gh/zklaus/60/orig and run ghstack).

UNSTABLE - The following jobs are marked as unstable, possibly due to flakiness on trunk:

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@pytorch-bot pytorch-bot Bot added the module: mkldnn Related to Intel IDEEP or oneDNN (a.k.a. mkldnn) integration label May 22, 2026
@pytorch-bot
Copy link
Copy Markdown

pytorch-bot Bot commented May 22, 2026

This PR needs a release notes: label

If your changes are user facing and intended to be a part of release notes, please use a label starting with release notes:.

If not, please add the topic: not user facing label.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "topic: not user facing"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

module: mkldnn Related to Intel IDEEP or oneDNN (a.k.a. mkldnn) integration open source

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants