[question] How to make CUDA version affect package_id about conan HOT 5 CLOSED

Happy to help!

Let us know if it works as expected, don't hesitate to create new tickets for any further question or issue you might have.

from conan.

Hi @aroidzap

Thanks for your question.

Hello, I'm trying to find out, how to work with Conan packages, that are built with different versions of CUDA.

I think that it depends on the use case.

If the packages are very specific to be built with CUDA, because they have CUDA code in it, then maybe the best would be to have a cuda custom setting in settings.yml and then it can be added directly in the recipes like settings = "os", "compiler", ..., "cuda" or something in that line

Then, there are packages that are not CUDA-accelerated, for example, a normal zlib recipe will not be affected by CUDA at all, even if some other packages in the dependency graph. So we don't want to inject the CUDA version to absolutely all packages in all situations. It seems that it should be packages that define that they want to be affected by CUDA.

There are several mechanisms to affect the package-id. Recipes can for example define what they want in their package_id() method, and force an option value, or even a conf to be part of the package_id. So the value of the CUDA version could be provided for example via a user.xxx:yyy conf value.

It would be best, if all recipes, that needs CUDA, requires some CUDA meta package. This package could be "provided" using [platform_requires] feature

This is not possible, the platform_requires are a replacement for some already existing requires in the recipes, but the recipes should have already declared some requires in them.

@jcar87 has been doing some progress in some "foundations" of using CUDA with Conan, but nothing yet for ConanCenter.

from conan.

Thanks for a quick response. In my use-case I want to avoid incompatible packages being used. I don't mind that much if there are redundant / duplicate packages that are same but have different package_id.

For me the best workaround would be to add something to the profile, that would affect all package_ids (maybe add some suffix) without the need of modifying any package recipe.

This way I could add CUDA version, CUDA architectures or whatever and packages won't be consumed if there is some possible incompatibility.

Maybe even better would be some feature so I can globally inject some require to all packages being used. Maybe some kind of pre_require hook https://docs.conan.io/2/reference/extensions/hooks.html?

from conan.

For me the best workaround would be to add something to the profile, that would affect all package_ids (maybe add some suffix) without the need of modifying any package recipe.

That is straightforward:

• Add some subsetting to the default settings.yml (can be done in settings_user.yml, with a default to null, so it can be left undefined, and not affect packages when not using cuda. This cude subsetting can have other subsettings, maybe cuda.version, cuda.sdk. Or you might want to add directly cuda_version as a subsetting for example of the compiler.
• Add in your profile the compiler.cuda.version = xxxx that you want.

That will create all packages with that specific package_id for that specific cuda version. This will be a bit inefficient, having to build more binaries than necessary for many libraries that don't depend on CUDA, but if it is what you want, it should take you only a couple of minutes to add it. You can check more on https://docs.conan.io/2/reference/binary_model/extending.html#custom-settings

from conan.

Thank you very much!

from conan.