-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
Update for CUDA 12.2.2 #8
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
Currently only |
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.
Thanks Alex! 🙏
Had some comments below
Also is the NVVM package being split out too? Edit: Nvm this is answered above
We may also want to think about a metapackage for all the CRT bits combined for easier use Edit: Nvm this is also answered above
Co-authored-by: Bradley Dice <[email protected]>
I agree with brad on the |
@@ -129,21 +128,21 @@ outputs: | |||
binary_relocation: False |
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.
Probably ok to keep this. Though quick question, do we have any libraries still here to corrupt? Only see the static library below, which I think patchelf
shouldn't touch
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.
Agreed this isn't doing anything now. Left it in since the relocation only seems to break things for us.
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.
Have some questions and suggestions, but approving so that I'm not blocking when I leave for the holidays.
- {{ pin_subpackage("cuda-crt-tools", exact=True) }} | ||
- {{ pin_subpackage("cuda-nvvm-tools", exact=True) }} |
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 do we need these in host? I would have expected them to only be run requirements, especially since they only contain binaries.
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.
The files
constrain above is grabbing bin/*
. It may make sense to include these just to avoid repackaging duplicate files that either of these packages would already have
Admittedly bin/*
may be too sweeping. Though it does ensure that we have gotten everything else that was in bin
that is not included in any other package
@@ -72,18 +73,14 @@ outputs: | |||
- "*/api-ms-win-core-winrt-*.dll" # [win] | |||
run_exports: | |||
strong: | |||
- cuda-version >={{ cuda_version }},<{{ cuda_version.split(".")[0]|int + 1 }} | |||
- cuda-version >={{ cuda_version }},<{{ cuda_version_next_major }} |
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.
Maybe put this whole constraint into a variable? It gets used numerous times.
- {{ pin_subpackage("cuda-crt-dev_" + target_platform, exact=True) }} | ||
- {{ pin_subpackage("cuda-nvvm-dev_" + target_platform, exact=True) }} |
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.
Same question as above re: why this is needed.
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.
As these are -dev
packages, they would make sense to keep (especially if there is something linking to them)
requirements: | ||
build: | ||
- sysroot_{{ target_platform }} 2.17 # [linux] | ||
host: | ||
- arm-variant * {{ arm_variant_type }} # [aarch64] | ||
- cuda-version {{ cuda_version }} | ||
- cuda-cudart-dev | ||
- {{ pin_subpackage("cuda-nvvm-impl", exact=True) }} |
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.
One more possibly unnecessary host (just marking to make them easier to find in case they can be removed).
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.
As we are only packaging one static library here that shouldn't be packaged anywhere else, this is probably safe to drop.
- test -d $PREFIX/bin/crt # [linux] | ||
- test -f $PREFIX/bin/crt/link.stub # [linux] | ||
- if not exist %LIBRARY_BIN%\crt\link.stub exit 1 # [win] | ||
about: |
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.
Not at all required for this PR, but does conda support YAML anchors? If so, we should use them for the about rather than duplicating it once per output in these recipes. We could use an anchor override for the description/summary, which are the only fields that change. If we were to apply it, would recommend doing so to any of our packages with multiple outputs.
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.
Instead of doing a bunch of YAML changes here would suggest someone draft a PR of the changes they would like to make and we can review separately. Let's keep this focused on the 12.2 update and related changes. Just want to keep this tightly scoped so we can get this done reasonably quickly |
I agree with @jakirkham on deferring YAML simplification. However, there are a few questions from @vyasr about packages in |
Would think the main reason to include a package in Would be tempted to leave them as-is If someone wants to test dropping them offline, that seems ok, but it also seems ok to punt that work into another issue handled separately from this PR |
Thanks all! 🙏 |
Needed another re-render to update the README. Done with PR ( #11 ) |
Compiler for CUDA applications. | ||
doc_url: https://docs.nvidia.com/cuda/index.html | ||
|
||
- name: cuda-nvvm-dev_{{ target_platform }} |
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.
This needs to be noarch: generic
just like cuda-crt-dev_{{ target_platform }}
is
It is needed because cuda-nvcc-dev_{{ target_platform }}
is noarch: generic
and depends on both of these
Without noarch: generic
the compiler becomes uninstallable in cross-compilation workloads
- name: cuda-nvvm-dev_{{ target_platform }} | |
- name: cuda-nvvm-dev_{{ target_platform }} | |
build: | |
noarch: generic |
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.
Fixing in PR ( #12 ), which has more context
xref: conda-forge/cuda-feedstock#13
Fixes #4