feat(conda): port conda recipe to rattler-build #137
Conversation
| CUDA_VERSION="$(cat pynvjitlink/CUDA_VERSION)" | ||
| export CUDA_VERSION | ||
|
|
||
| cat > cuda_compiler_version.yaml << EOF | ||
| cuda_compiler_version: | ||
| - "${CUDA_VERSION}" | ||
| EOF |
There was a problem hiding this comment.
This was done to ensure cuda_compiler_version matched the intended CUDA_VERSION set in that file. That is the one canonical place used to CUDA version in this feedstock. It is also used by wheels to install the right Linux CUDA packages when building as well
Additionally setting cuda_compiler_version this way ensured it was considered when generating the package string hash. Maybe rattler-build handles this differently
There was a problem hiding this comment.
I can load it from the file directly and make sure it's part of the package string
| schema_version: 1 | ||
|
|
||
| context: | ||
| cuda_version: ${{ (env.get("RAPIDS_CUDA_VERSION") | split("."))[:2] | join(".") }} |
There was a problem hiding this comment.
This project does things a bit differently than the rest of RAPIDS by using the CUDA_VERSION file noted above. Let's see if we can align on that somehow. Perhaps that can be done via setting an environment variable above
| requirements: | ||
| build: | ||
| - cmake >=3.24.4,!=3.30.0 | ||
| - ninja | ||
| - ${{ compiler("c") }} | ||
| - ${{ compiler("cxx") }} | ||
| - ${{ compiler("cuda") }} | ||
| - ${{ stdlib("c") }} |
There was a problem hiding this comment.
Personally find it a little easier to have compilers first and then build dependencies. That way it is easy to see what language features are used. Then look at build tools after
| - rapids-build-backend >=0.3.0,<0.4.0dev0 | ||
| - scikit-build-core >=0.10.0 | ||
| run: | ||
| - ${{ pin_compatible("cuda-version", upper_bound="x", lower_bound="x") }} |
There was a problem hiding this comment.
The upper bound needs to include minor version here. This has to do without libnvjitlink works in that it can only generate code that is usable by a matching CUDA version or older. It is also how we have it set in meta.yaml
Additionally would suggest ordering lower_bound then upper_bound
| - ${{ pin_compatible("cuda-version", upper_bound="x", lower_bound="x") }} | |
| - ${{ pin_compatible("cuda-version", lower_bound="x", upper_bound="x.x") }} |
|
Thanks @jakirkham ! Applied your suggestions |
There was a problem hiding this comment.
Thanks @gforsyth and @jakirkham! I have one other comment, otherwise LGTM.
| - ${{ compiler("cxx") }} | ||
| - ${{ compiler("cuda") }} | ||
| - ${{ stdlib("c") }} | ||
| - cmake >=3.24.4,!=3.30.0 |
There was a problem hiding this comment.
We bumped this for the rest of RAPIDS. Probably wouldn't hurt to match here since it's just a build-time requirement.
| - cmake >=3.24.4,!=3.30.0 | |
| - cmake >=3.30.4 |
|
/merge |
- Update to CUDA 12.9 (rapidsai#138) - feat(conda): port conda recipe to rattler-build (rapidsai#137) - Download build artifacts from Github for CI (rapidsai#136) - Moving wheel builds to specified location and uploading build artifacts to Github (rapidsai#135) - Use mainline shared-workflows again (rapidsai#134)
- Update to CUDA 12.9 (#138) - feat(conda): port conda recipe to rattler-build (#137) - Download build artifacts from Github for CI (#136) - Moving wheel builds to specified location and uploading build artifacts to Github (#135) - Use mainline shared-workflows again (#134) <!-- Thank you for contributing to pynvjitlink :) Here are some guidelines to help the review process go smoothly. 1. Please write a description in this text box of the changes that are being made. 2. Please ensure that you have written units tests for the changes made/features added. 3. If you are closing an issue please use one of the automatic closing words as noted here: https://help.github.com/articles/closing-issues-using-keywords/ 4. If your pull request is not ready for review but you want to make use of the continuous integration testing facilities please label it with `[WIP]`. 5. If your pull request is ready to be reviewed without requiring additional work on top of it, then remove the `[WIP]` label (if present) and replace it with `[REVIEW]`. If assistance is required to complete the functionality, for example when the C/C++ code of a feature is complete but Python bindings are still required, then add the label `[HELP-REQ]` so that others can triage and assist. The additional changes then can be implemented on top of the same PR. If the assistance is done by members of the rapidsAI team, then no additional actions are required by the creator of the original PR for this, otherwise the original author of the PR needs to give permission to the person(s) assisting to commit to their personal fork of the project. If that doesn't happen then a new PR based on the code of the original PR can be opened by the person assisting, which then will be the PR that will be merged. 6. Once all work has been done and review has taken place please do not add features or make changes out of the scope of those requested by the reviewer (doing this just add delays as already reviewed code ends up having to be re-reviewed/it is hard to tell what is new etc!). Further, please do not rebase your branch on main/force push/rewrite history, doing any of these causes the context of any comments made by reviewers to be lost. If conflicts occur against main they should be resolved by merging main into the branch used for making the pull request. Many thanks in advance for your cooperation! -->
Ports the condabuild recipe over to use rattler-build instead.
Contributes to rapidsai/build-planning#47
Contributes to rapidsai/build-planning#84
The only other major change here is that I am no longer passing in the
cuda_compiler_versionvariant variable using a separate file (catted infrom the
pynvjitlink/CUDA_VERSIONfile. Instead, grabbing it from theRAPIDS_CUDA_VERSIONenv-var.If we would prefer to read it from the file, I'll add that directly to the recipe, instead of side-loading it in the ci build script.