Add python-cudnn-frontend

[weiji14]

The cuDNN FrontEnd(FE) API is a C++ header-only library that wraps the cuDNN C backend API. Repo at https://github.com/NVIDIA/cudnn-frontend

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/cudnn-frontend) and found some lint.

Here's what I've got...

For recipes/cudnn-frontend:

• The home item is expected in the about section.
• If python is a host requirement, it should be a run requirement.
• Non noarch packages should have python requirement without any version constraints.

For recipes/cudnn-frontend:

• This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

[conda-forge-webservices]

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 (recipes/cudnn-frontend) and found it was in an excellent condition.

[weiji14]

@conda-forge/help-python-c, ready for review!

[xhochy]

If this is a header-only library, why does it need Python?

[weiji14]

This is built with the Python bindings (https://github.com/NVIDIA/cudnn-frontend?tab=readme-ov-file#python-api). I could try to remove python from the host and runtime deps and see if it works?

[xhochy]

It depends on what you want to achieve with this package. If it should be one for the headers, you should remove python. If you want to have the Python bindings, then this looks good.

[weiji14]

Yes, I'll be using this with the python bindings. Should I add a -python suffix perhaps?

[xhochy]

Yes, I'll be using this with the python bindings. Should I add a -python suffix perhaps?

For these cases, we normally add a python- prefix.

[xhochy]

This should be in host and then you probably don't need to explicitly mention it in run anymore.

[xhochy]

This should solely be in host, i.e. should also not appear in build.

[weiji14]

Ok, done! Thanks again for checking 😃

[conda-forge-webservices]

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 (recipes/cudnn-frontend) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/cudnn-frontend:

• In your conda_build_config.yaml, please change the name of MACOSX_DEPLOYMENT_TARGET, to c_stdlib_version!

[weiji14]

In your conda_build_config.yaml, please change the name of MACOSX_DEPLOYMENT_TARGET, to c_stdlib_version!

Guessing that this is a false alarm since there's no conda_build_config.yaml file added? Can probably just ignore also since this recipe won't be built on macOS.