conan-io / conan

Conan - The open-source C and C++ package manager
https://conan.io
MIT License
8.25k stars 980 forks source link

[feature] Cuda flags #16532

Closed danielnilsson9 closed 4 months ago

danielnilsson9 commented 4 months ago

What is your suggestion?

When setting up conan for cross compiling you must pass a few extra flags when building with clang.

For c and c++ this can be done like this:

tools.build:sysroot=...
tools.build:cflags+=["--target=aarch64-linux-gnu"]
tools.build:cxxflags+=["--target=aarch64-linux-gnu"]
tools.build:exelinkflags+=["--target=aarch64-linux-gnu -fuse-ld=lld"]
tools.build:sharedlinkflags+=["--target=aarch64-linux-gnu -fuse-ld=lld"]

CMake has native language support for CUDA and I'm wondering if it would be a good idea to support passing cuda flags the same way?

tools.build:cudaflags+=["-target-dir aarch64-linux", "-Xcompiler --target=aarch64-linux-gnu"]

tools.build:cudaflags which would map to CMake variable CMAKE_CUDA_FLAGS_INIT.

I have no idea how it would apply to other build generators though.. I figures since cuda is supported in tools.build:compiler_executables it could be reasonable thing to support passing extra flags too.

Workaround for CMake is currently to create a user_toolchain and define it there but it is a bit more cumbersome.

Have you read the CONTRIBUTING guide?

franramirez688 commented 4 months ago

Hi @danielnilsson9

Thanks for the proposal. I think it's an interesting one what you're describing here. Let me put it as a look-into to talk to the team about it. From my point of view, it could be something like:

[conf]
tools.cmake.cmaketoolchain:lang_flags={"cuda": [], "objc": [], "xxxx": []}

I will give you a better answer ASAP 😁

danielnilsson9 commented 4 months ago

I just found the newly introduced (2.4.0) cmaketoolchain:extra_variables which solves the issue for me: https://github.com/conan-io/conan/pull/16242

So maybe that is the way to go in this case :)

franramirez688 commented 4 months ago

Absolutely 😁 My fault then, I completely missed this new way to enter any CMake-specific variables πŸ˜… Thanks again for your update!