🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/137693

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki or our office hours

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit ab3b81d with merge base 5c3ba6f ():
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@malfet could you help review this PR?

@malfet Sorry for this. Just a reminder in case this series PR is ignored.

@malfet May I know if this code change is reasonable to you?

@malfet May I know if this code change is reasonable to you?

I still don't understand, what problem this PR is trying to solve? Can you please add a regression test or something? TORCH_LIBRARY should only contain reference to libtorch, which is a proxy library for both torch_cpu and torch_cuda. Why one needs to add explicit dependency to libtorch_cuda.so? When depending on libtorch.so is not enough?

I go through the CMake code again. In my understanding, these pieces of code seem to find all libs related to torch such as torch_cpu, torch_cuda, c10, c10_cuda, and torch to TORCH_LIBRARY, and even nnpack, mkldnn, kineto these libs that PyTorch depends on. In most situations, libtorch.so, a proxy lib, is enough to find the dependency, but sometimes might be over-enough.
This PR intends to add torch_cuda to TORCH_LIBRARY in BUILD_SHARED_LIBS mode to flexibly facilitate the user experience in the situation where the user only wants to link torch_cuda. I could take only link torch_cpu as an example: ipex CPU code only would like to link libtorch_cpu rather than libtorch_cpu and libtorch_cuda.
If this PR code change is not reasonable to you, I would like to close it.

If this PR code change is not reasonable to you, I would like to close it.

There are two use-cases in my mind:

• C++ API users, who should never link with anything directly against libtorch_cuda or c10 or kineto, as implementation of all methods decorated with TORCH_API should be in libtorch_cpu.so
• Extension developers who might need to link to kineto, c10_cuda, cudnn etc should write their scripts in a way to explicitly search for those dependencies, as pytorch might change the underlying structure any time, but if they need something from the 3rd party libraries, they should not assume they'll be available thru PyTorch

Do you mean if C++ user would like to use some APIs provided by libtorch_cuda.so such as getCUDADeviceAllocator. It is enough to link against libtorch.so rather than libtorch_cuda.so. If yes, I think you are right!