Repository navigation
build: enable CUDA 12 development from main #3315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
f56e867
c6b349a
34edebb
e3599f7
e18c3d4
968ad32
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,10 +8,33 @@ guide for package-specific conventions and workflows. | |
| ## Package map | ||
|
|
||
| - `cuda_pathfinder/`: Pure-Python library discovery and loading utilities. | ||
| - `cuda_bindings_13/`: Low-level CUDA host API bindings (Cython-heavy). | ||
| - `cuda_bindings_12/`: CUDA 12.9 maintenance bindings (Cython-heavy). | ||
| - `cuda_bindings_13/`: Current CUDA 13 bindings (Cython-heavy). | ||
| - `cuda_core/`: High-level Pythonic CUDA APIs built on top of bindings. | ||
| - `cuda_python/`: Metapackage and docs aggregation. | ||
|
|
||
| ## Changes across bindings majors | ||
|
|
||
| Both `cuda_bindings_12/` and `cuda_bindings_13/` are maintained on `main`. | ||
| When implementing or reviewing a change in either root, inspect the other | ||
| root's corresponding implementation, tests, and relevant build, packaging, | ||
| or documentation files, including files absent from the diff. Check shared | ||
| instructions and configuration affected by the change too. Apply this check | ||
| in both directions, and when changing shared build helpers, generation | ||
| inputs, CI selection, or release routing. | ||
|
|
||
| - Make matching changes where the affected behavior applies to both roots. | ||
| Preserve intentional differences in supported APIs, toolkit inputs, source | ||
| layout, and compatibility behavior. Do not copy changes mechanically or add an unsupported API to make the roots match. | ||
| - Follow each package's generation instructions: change the generation source | ||
| and regenerate each affected root against its own inputs. Do not hand-edit | ||
| generated output. | ||
| - In the implementation or review summary, name the counterpart files inspected | ||
| and identify the matching changes or explain concretely why none are needed. | ||
| Reviewers must verify that assessment and flag omitted applicable changes; | ||
| absence from the diff is not evidence that the other root is unaffected. | ||
| - Preserve byte-for-byte invariants for package-local copies of shared helpers. | ||
|
|
||
| # Git-derived version lifecycle | ||
|
|
||
| Package versions are derived from reachable Git tags by `setuptools-scm`. | ||
|
|
@@ -36,6 +59,20 @@ For each package tag namespace and target release `X.Y.Z`: | |
| existing history. | ||
| - Treat pushed tags as immutable. Correct an unsuitable tagged state with a | ||
| new versioned milestone rather than moving or replacing the existing tag. | ||
| - Reserve a new preview target from the next globally unused release number, | ||
| checking canonical tags and coordinating releases on every maintenance or | ||
| stabilization branch. A release on another branch consumes that number even | ||
| when its tag is not reachable from `main`. Update `scm-bootstrap-release` | ||
| before another build if such a release consumes its target; do not bump the | ||
| field per PR or use it to override suitable reachable tags. | ||
|
Comment on lines
+65
to
+67
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand this sentence. |
||
| - Moving a package's SCM selector to a new toolkit minor also needs a matching | ||
| reachable milestone. Updating the selector alone can produce an incorrect | ||
| placeholder version. Validate previews with local tags in an independent | ||
| disposable clone until the release history supplies the right milestone. | ||
|
Comment on lines
+68
to
+71
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about this design is enforcing this requirement? It would be great to fix this because it negates a large part of the usefulness of |
||
| - For a newly integrated maintenance root, create its first retained internal | ||
| milestone only after the integration group has landed and been validated on | ||
| `main`. Retained tag creation requires an explicit maintainer decision; | ||
| preparation of a PR stack does not authorize creating or pushing it. | ||
|
Comment on lines
+72
to
+75
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think we will ever have another "newly integrated maintenance root". Our next maintenance root will be |
||
|
|
||
| Use the package's established tag namespace, such as `vX.Y.Z...` for | ||
| `cuda-bindings` and `cuda-python`, `cuda-core-vX.Y.Z...` for `cuda-core`, and | ||
|
|
||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -48,6 +48,14 @@ The list of available interfaces is: | |||||
| * cuFile | ||||||
| * NVML | ||||||
|
|
||||||
| ## Bindings source roots | ||||||
|
|
||||||
| Current CUDA 13 bindings live in [`cuda_bindings_13/`](cuda_bindings_13/), and | ||||||
| CUDA 12.9 sources have a separate | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
| [developer environment](cuda_bindings_12/README.md). Both roots build the same | ||||||
| `cuda-bindings` distribution and `cuda.bindings` namespace; develop and test | ||||||
| them in separate environments. | ||||||
|
|
||||||
| ## License | ||||||
|
|
||||||
| CUDA Python is licensed under the [Apache License 2.0](./LICENSE). Third-party | ||||||
|
|
@@ -59,7 +67,8 @@ The root `LICENSE` governs the repository as a whole: | |||||
|
|
||||||
| | Subproject | License | License file | | ||||||
| | ---------------- | ---------- | -------------------------------------------------------- | | ||||||
| | `cuda.bindings` | Apache-2.0 | [`cuda_bindings_13/LICENSE`](./cuda_bindings_13/LICENSE) | | ||||||
| | `cuda.bindings` (CUDA 13) | Apache-2.0 | [`cuda_bindings_13/LICENSE`](./cuda_bindings_13/LICENSE) | | ||||||
| | `cuda.bindings` (CUDA 12) | Apache-2.0 | [`cuda_bindings_12/LICENSE`](./cuda_bindings_12/LICENSE) | | ||||||
| | `cuda.core` | Apache-2.0 | [`cuda_core/LICENSE`](./cuda_core/LICENSE) | | ||||||
| | `cuda.pathfinder`| Apache-2.0 | [`cuda_pathfinder/LICENSE`](./cuda_pathfinder/LICENSE) | | ||||||
| | `cuda-python` | Apache-2.0 | [`cuda_python/LICENSE`](./cuda_python/LICENSE) | | ||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| # SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| [build-system] | ||
| requires = ["setuptools>=77.0.0"] | ||
| build-backend = "setuptools.build_meta" | ||
|
|
||
| [project] | ||
| name = "cuda-python-ci-tools" | ||
| version = "0.0.0" | ||
| description = "Private CI support for the CUDA Python repository" | ||
| authors = [{ name = "NVIDIA Corporation" }] | ||
| license = "Apache-2.0" | ||
| requires-python = ">=3.11" | ||
| dependencies = [ | ||
| "packaging==26.0", | ||
| "PyYAML==6.0.3", | ||
| "setuptools-scm>=8,!=10.1", | ||
| ] | ||
|
|
||
| [project.optional-dependencies] | ||
| test = ["pytest==9.1.0", "wheel"] | ||
|
|
||
| [tool.setuptools] | ||
| packages = ["ci", "ci.tools"] | ||
| package-dir = { ci = "." } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why Python 3.12? Odd choice. I think the best conservative choice is 3.11.