Always linking gbench statically

[cjnolet]

This just makes more sense. There's no inherent reason folks should have to have gbench installed just to run benchmarks.

[vyasr]

Does this make sense to do more generally? @robertmaynard are there known issues with statically linking gbench? If not, should we move this logic into rapids_cpm_gbench and make this target available for all of RAPIDS to use in this way?

[bdice]

Does this make sense to do more generally? @robertmaynard are there known issues with statically linking gbench? If not, should we move this logic into rapids_cpm_gbench and make this target available for all of RAPIDS to use in this way?

I'd also like to know if we should do the same for nvbench, if applicable.

[cjnolet]

@bdice @vyasr @robertmaynard given that we are almost always linking gbench (and gtest) directly into executable binaries and not into libraries, it would be ideal to make the executables as self-contained as possible, with the exception of libraft.

As for the reasoning behind this change- there's currently a gbench version conflict happening in some environments where a different version is installed on the system and we get an library not found error as a result. Gbench is lightweight enough that we shouldn't even have to require it as a runtime dependency. Not many systems are already going to have it installed for runtime anyways.

Whether we do this at rapids-cmake or do this directly for raft doesn't matter to me, but we need to alleviate this burden because too many users (including our own developers) have encountered this problem.

[robertmaynard]

The proper approach will be to request rapids-cmake to provide you a static version of gtest/gbench. Since this approach doesn't work with an installed version

[robertmaynard]

This won't work when google benchmark is pre-built and coming from the environment. The sources in that case will be empty and you will fail to have any gtest/gbench in your final executable.

[robertmaynard]

Does this make sense to do more generally? @robertmaynard are there known issues with statically linking gbench? If not, should we move this logic into rapids_cpm_gbench and make this target available for all of RAPIDS to use in this way?

The thing we lose is the ability to use the conda version of gbench/gtest since they only come as shared. So as long as we are fine with that we can update rapids-cmake to provide a static version when requested.

[robertmaynard]

Does this make sense to do more generally? @robertmaynard are there known issues with statically linking gbench? If not, should we move this logic into rapids_cpm_gbench and make this target available for all of RAPIDS to use in this way?

I'd also like to know if we should do the same for nvbench, if applicable.

NVBench explicitly builds shared we will need to look into this

[bdice]

Does this make sense to do more generally? @robertmaynard are there known issues with statically linking gbench? If not, should we move this logic into rapids_cpm_gbench and make this target available for all of RAPIDS to use in this way?

The thing we lose is the ability to use the conda version of gbench/gtest since they only come as shared. So as long as we are fine with that we can update rapids-cmake to provide a static version when requested.

That's fine by me -- part of my incentive to align the conda versions of gbench/gtest when I last worked on it was to ensure that environments had compatible versions. This is also achieved (perhaps more cleanly) by static linkage.