Introduce libcuvs-headers and libcuvs-static CMake components and conda packages

[divyegala]

The PR adds a new target cuvs-cpp-headers that is part of the main cuvs-exports set. It also separates out cuvs_static as its own optional component.

Two new conda packages are added to reflect the aforementioned changes, namely libcuvs-headers and libcuvs-static.

[robertmaynard]

Working through the testing the changes locally, my biggest thought so far is that we can't have an option to disable the headers install. They are a required component if we are providing the shared or static version of libcuvs.so

[divyegala]

@robertmaynard that makes sense, I did not like introducing that option either.

The other problem (maybe okay for this release) is that we'll need a separate target for the C library if we want to build only once and ship the C++ shared and static libraries separately. As it stands currently, I believe the C library can only link to the C++ shared library.

[robertmaynard]

The other problem (maybe okay for this release) is that we'll need a separate target for the C library if we want to build only once and ship the C++ shared and static libraries separately. As it stands currently, I believe the C library can only link to the C++ shared library.

Yeah for the conda / wheel packages the C library will need a dependency on the shared library. For things like java builds and the prebuilt tarball the C library links against the static version ( #1524 ).

[robertmaynard]

Realized I need to also make cuvs::cuvs_static also be automatically imported when it exists. Adding that now

[robertmaynard]

Realized I need to also make cuvs::cuvs_static also be automatically imported when it exists. Adding that now

Addressed in the latest commit

[bdice]

This is very close to what we would want in a -dev package but perhaps reversed -- where libcuvs would be only runtime libs while libcuvs-dev would be runtime libs plus headers. See proposal in rapidsai/build-planning#46.

What is our main goal in splitting out the headers? I am curious if that approach for -dev packages still makes sense or not. It might be different in a world with JIT where runtime always requires headers.

[robertmaynard]

We need the headers for both the cuvs and cuvs-static packages to work in a -dev sense, but don't want to have two conda packages that clobber the same headers so that is why they are in cpp-headers.

The extra complexity is that I am also planning for splitting out the C API from the libcuvs conda package. That would allow us to have libcuvs-c-dev which only installs the libcuvs.so, libcuvs_c.so and the C headers

In most cases, ${lib}-dev will likely just be a metapackage that pulls in ${lib} and ${lib}-headers

It looks like we match the proposal in 46