-
Notifications
You must be signed in to change notification settings - Fork 5
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
Ensure ninja is used in wheel builds 🥷 #146
Comments
Just reviewed all of these libraries, happy to say that all but cuGraph are successfully building with Ninja today. So the changes for this issue will just be minor cleanup and a bit of added protection against this bug re-occurring. Given that and where we are in the current release cycle, I'm going to target this issue and the PRs at |
Thanks James! 🙏 Since we are looking, can we confirm the same is true for Conda? |
We can check on conda too, just to be sure, but I think we're in good shape on that front. |
Contributes to rapidsai/build-planning#146 Proposes: * setting `[tool.scikit-build].ninja.make-fallback = false`, so `scikit-build-core` will not silently fallback to using GNU Make if `ninja` is not available Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Bradley Dice (https://github.com/bdice) URL: #1804
✅ confirmed I looked through logs from recent nightly builds for all the projects. C++ builds for conda packages are usually directly driven by CMake (instead of via
Think we are good for conda builds. |
I've opened PRs for this issue for all the repo, but intentionally leaving most in draft + not triggering CI right now, to save CI resources for people who are doing time-sensitive work towards the next release. Will start CI for them next week. |
Contributes to rapidsai/build-planning#146 Proposes including all groups in `dependencies.yaml` with `output_types: pyproject` in `output_types: requirements` as well. So that, for example, they show up in the solved environment in RAPIDS devcontainers (https://github.com/rapidsai/devcontainers). Also standardizes the ordering in those groups (there was a mix of `requirements, pyproject` and `pyproject, requirements`... this PR alphabetizes them). Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Bradley Dice (https://github.com/bdice) URL: #75
Contributes to rapidsai/build-planning#146 Proposes: * setting `[tool.scikit-build].ninja.make-fallback = false`, so `scikit-build-core` will not silently fallback to using GNU Make if `ninja` is not available * including all groups in `dependencies.yaml` with `output_types: pyproject` in `output_types: requirements` as well. - *So that, for example, they show up in the solved environment in RAPIDS devcontainers (https://github.com/rapidsai/devcontainers)* Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Bradley Dice (https://github.com/bdice) URL: #2563
Contributes to rapidsai/build-planning#146 Proposes: * setting `[tool.scikit-build].ninja.make-fallback = false`, so `scikit-build-core` will not silently fallback to using GNU Make if `ninja` is not available * including all groups in `dependencies.yaml` with `output_types: pyproject` in `output_types: requirements` as well. - *So that, for example, they show up in the solved environment in RAPIDS devcontainers (https://github.com/rapidsai/devcontainers)* Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Bradley Dice (https://github.com/bdice) URL: #6286
Contributes to rapidsai/build-planning#146 Proposes: * setting `[tool.scikit-build].ninja.make-fallback = false`, so `scikit-build-core` will not silently fallback to using GNU Make if `ninja` is not available Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Bradley Dice (https://github.com/bdice) URL: #1529
Contributes to rapidsai/build-planning#146 Proposes: * setting `[tool.scikit-build].ninja.make-fallback = false`, so `scikit-build-core` will not silently fallback to using GNU Make if `ninja` is not available * including all groups in `dependencies.yaml` with `output_types: pyproject` in `output_types: requirements` as well. - *So that, for example, they show up in the solved environment in RAPIDS devcontainers (https://github.com/rapidsai/devcontainers)* Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Bradley Dice (https://github.com/bdice) URL: #636
Contributes to rapidsai/build-planning#146 Proposes: * setting `[tool.scikit-build].ninja.make-fallback = false`, so `scikit-build-core` will not silently fallback to using GNU Make if `ninja` is not available Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Bradley Dice (https://github.com/bdice) URL: #612
Contributes to rapidsai/build-planning#146 Proposes: * setting `[tool.scikit-build].ninja.make-fallback = false`, so `scikit-build-core` will not silently fallback to using GNU Make if `ninja` is not available * including all groups in `dependencies.yaml` with `output_types: pyproject` in `output_types: requirements` as well. - *So that, for example, they show up in the solved environment in RAPIDS devcontainers (https://github.com/rapidsai/devcontainers)* Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Gil Forsyth (https://github.com/gforsyth) URL: #123
Contributes to rapidsai/build-planning#146 Closes #262 Proposes: * setting `[tool.scikit-build].ninja.make-fallback = false`, so `scikit-build-core` will not silently fallback to using GNU Make if `ninja` is not available * adding `devcontainers` CI jobs here ## Notes for reviewers ### Why add `devcontainers` CI jobs in this PR? The `devcontainers` are useful for interactive development on this project (including for outside contributors). `ucxx` building successfully in them is also important for other all-of-RAPIDS builds, like those from https://github.com/rapidsai/devcontainers and other builds based on that repo. Having CI jobs run in PRs (as most of RAPIDs does) allows us to catch issues right here in `ucxx` when they happen, instead of only finding out when `ucxxx` is built as part of a larger devcontainers-based build. ### How did you set up the `.devcontainers` folder? Copied https://github.com/rapidsai/cugraph/tree/branch-25.04/.devcontainer and changed all the `cugraph` references to `ucxx`. Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Bradley Dice (https://github.com/bdice) URL: #363
…dependencies cleanup (#820) Contributes to rapidsai/build-planning#146 * updates `setuptools` dependency to `>=61.0.0` ([the first version to support `pyproject.toml`](https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html)) * makes `numpydoc` pins in testing and docs the same * removes ceiling on `sphinx`, changes `sphinx` dependency to `>=8.0.0` (matching what was recently done across the RAPIDS, e.g. in rapidsai/cuml#6195) * ensures `numpydoc` makes it into `requirements` output from `rapids-dependency-file-generator` Authors: - James Lamb (https://github.com/jameslamb) Approvers: - https://github.com/jakirkham URL: #820
Contributes to rapidsai/build-planning#146 Proposes: * setting `[tool.scikit-build].ninja.make-fallback = false`, so `scikit-build-core` will not silently fallback to using GNU Make if `ninja` is not available Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Bradley Dice (https://github.com/bdice) URL: #17894
Description
We found recently that some projects' wheel builds were falling back to GNU Make because
ninja
was (unintentionally) not available in their build environments.Noticed by the presence of lines like this in CMake output:
*** Building project with Unix Makefiles...
We should audit all of the RAPIDS libraries for the following:
ninja
being used in wheel-building environmentsninja.make-fallback = false
in[tool.scikit-build]
inpyproject.toml
(to raise an error ifninja
is not available)dependencies.yaml
,output-types:
should almost always contains either both ofpyproject
andrequirements
or neitherBenefits of this work
Approach
These can be done in any order.
libraries about to enter code freeze
others
Notes
related: #108
The text was updated successfully, but these errors were encountered: