[PATCH] D55269: [CUDA][OpenMP] Fix nvidia-cuda-toolkit detection on Debian/Ubuntu

Tue Dec 4 15:27:26 PST 2018

tra added a comment.

In D55269#1319319 <https://reviews.llvm.org/D55269#1319319>, @jdenny wrote:

> My real goal is to get clang and openmp working out of the box on Ubuntu.  Treating --cuda-path=/usr as a special case was just a way to get there.  It's odd apparently because nvidia-cuda-toolkit is odd.

It does not address the issue in principle -- if we add tweaks do deal with Ubuntu oddities, why shouldn't we also add tweaks for any other linux distro?
If you want to solve the issue in general you need to be able to tell where to find each component of CUDA SDK needed by clang. Once you have that flexibility, it will open a lot of possibilities to specify one of them incorrectly and fail in some strange way nobody has seen before. I don't think it's worth the effort.

I personally prefer to keep things as simple as possible. Clang expects to see a monolithic CUDA SDK installation, specified, if necessary, with one option.
Dealing with distro-specific way SUDA SDK may be split there is up to the distro maintainers. If they want Clang compilation work with their variant of CUDA installation, they can always create a shim the way Debian did.

As for cmake, it currently does not support clang as the CUDA compiler. Whatever detects CUDA install path apparently does not do it correctly on Ubuntu (it's the same problem of having CUDA SDK bits all over the place) and that's something that needs to be fixed there.

> I don't have a separate project using cmake.  The cmake files I'm referring to are clang's.  I'm just trying to make it easy to build clang and openmp and call clang on the command line under Ubuntu.
>  An easier workaround is to specify CUDA_TOOLKIT_ROOT_DIR when building llvm,

That would work, too.

> but my goal is make building on Ubuntu work without special configuration.  D40453 <https://reviews.llvm.org/D40453> was my hint that people already agreed that's a worthwhile pursuit.

And I believe that we did convince Debian that it's up to them to arrange their packages in a way that works with clang.
Granted, closer examination of the shim they've added shows that the shim is incomplete, but it's the right way to solve this problem, IMO.

> I'm not adamant that handling --cuda-path=/usr is the right solution.  But just adding IsUbuntu() is not a full solution, so I'm looking for advice on how to proceed.

Let's start with fixing OpenMP's cmake files. Once it no longer insists on specifying --cuda-path=/usr, and isUbuntu is in place, what is the remaining failure that you see?

Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55269/new/

https://reviews.llvm.org/D55269