Skip to content
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

Merged
merged 14 commits into from
Jan 5, 2024
Merged

Update for CUDA 12.2.2 #8

merged 14 commits into from
Jan 5, 2024

Conversation

adibbley
Copy link
Contributor

@adibbley adibbley commented Dec 18, 2023

@conda-forge-webservices
Copy link
Contributor

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 (recipe) and found it was in an excellent condition.

@adibbley
Copy link
Contributor Author

Currently only crt is split to new outputs, nvvm also needs to be split in this PR. In an effort to be consistent with the packages originally providing these files I matched their naming and structure. Metapackages should be added to conda-forge/cuda-nvcc-feedstock#32 as cuda-crt and cuda-nvvm

recipe/meta.yaml Outdated Show resolved Hide resolved
Copy link
Member

@jakirkham jakirkham left a 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

recipe/meta.yaml Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
@msarahan
Copy link
Member

I agree with brad on the major distinction. In my opinion, pin_subpackage is clearer about things coming from this specific recipe, but the net effect on the outcome is exactly the same. It's up to you on how you want to do it.

@@ -129,21 +128,21 @@ outputs:
binary_relocation: False
Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Contributor

@vyasr vyasr left a 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.

recipe/meta.yaml Show resolved Hide resolved
Comment on lines +46 to +47
- {{ pin_subpackage("cuda-crt-tools", exact=True) }}
- {{ pin_subpackage("cuda-nvvm-tools", exact=True) }}
Copy link
Contributor

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.

Copy link
Member

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 }}
Copy link
Contributor

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.

Comment on lines +94 to +95
- {{ pin_subpackage("cuda-crt-dev_" + target_platform, exact=True) }}
- {{ pin_subpackage("cuda-nvvm-dev_" + target_platform, exact=True) }}
Copy link
Contributor

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.

Copy link
Member

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)

recipe/meta.yaml Show resolved Hide resolved
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) }}
Copy link
Contributor

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).

Copy link
Member

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:
Copy link
Contributor

@vyasr vyasr Dec 20, 2023

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakirkham
Copy link
Member

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

@bdice
Copy link
Contributor

bdice commented Jan 4, 2024

I agree with @jakirkham on deferring YAML simplification. However, there are a few questions from @vyasr about packages in host that might not be necessary (?). I think these are somewhat pertinent to 12.2 but I would be okay with merging for now and addressing these separately. I think the next step would be either merge, or test what happens if those packages are removed from host.

#8 (comment)
#8 (comment)
#8 (comment)

@bdice bdice marked this pull request as ready for review January 4, 2024 23:32
@bdice bdice requested a review from a team as a code owner January 4, 2024 23:32
@jakirkham
Copy link
Member

Would think the main reason to include a package in host that is already in run would be to avoid clobbering or to satisfy linkage (or other) checks. It seems relatively safe to have the packages in host (if a little redundant). While there is some risk in dropping them (that we wind up with duplicate copies of files in different packages and thus clobbering errors at install time)

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

@jakirkham jakirkham merged commit b6f0f36 into conda-forge:main Jan 5, 2024
5 checks passed
@jakirkham
Copy link
Member

Thanks all! 🙏

@jakirkham
Copy link
Member

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 }}
Copy link
Member

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

Suggested change
- name: cuda-nvvm-dev_{{ target_platform }}
- name: cuda-nvvm-dev_{{ target_platform }}
build:
noarch: generic

Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create outputs for nvvm and crt
6 participants