[REVIEW] cmake: handle thrust via target

[germasch]

This is just a relatively straightforward switch from adding the thrust include dir manually to using a target. This also
changes CPM to prefer an external thrust if it can be found.

I figured I'd use this to pull in @allisonvacanti to ask whether I'm misusing something by using the Thrust::Thrust target directly, rather than calling thrust_create_target(). Since all I'm looking for is to get include path added, and RMM is clearly not designed for anything but CUDA, I'm hoping this is acceptable.

There are more problems down the road, when it comes to installing RMM while it depends on either an internal or an external thrust. But let's leave that for next.

[GPUtester]

Can one of the admins verify this patch?

[GPUtester]

Can one of the admins verify this patch?

[kkraus14]

ok to test

[alliepiper]

It would be best to use the thrust_create_target function to assemble a complete interface to Thrust. Thrust::Thrust is an incomplete interface specification -- it just sets the Thrust include path, and will not handle any dependencies (CUB is required on CUDA). thrust_create_target will also add some CMake checks that prevent multiple incompatible Thrust targets from being linked together.

Is there a reason that you want to avoid constructing a complete thrust interface target?

[germasch]

Is there a reason that you want to avoid constructing a complete thrust interface target?

Well, I guess it was the misguided idea of avoiding the trouble of having to pick a specific target, as in some sense, I'd prefer to let the user of RMM pick the specific configuration of Thrust they'd like to use (RMM itself doesn't really care that much, at least not for the host, though it definitely wants to use CUDA). But I think my plan leads to more problems than it solves ;(

In any case, I opened NVIDIA/thrust#1295 which seems like the better place to discuss this.

[germasch]

I agree with @allisonvacanti that using is thrust_create_target() is the way to go, so I switched to using that.

My main concern was that if I make my own thrust target, and the downstream user of rmm also makes their own target, we could end up with two, possibly incompatibly configured thrust's. While this can't be prevented 100%, the the thrust cmake config does recognize when this happens and throws an error, so it's not going to cause subtle problems.

[harrism]

Hopefully we can move cuDF in this direction too...