Clean up public api

[ChuckHastings]

We are exposing some internal implementation details in our public header files. This PR addresses exposing cuco in the public header files. It is the start of the effort to clean up the public API for libcugraph.

Ultimately our plan is to migrate the graph primitives into a separate library. This PR does move a bunch of the primitive headers out of the libcugraph public API.

[seunghwak]

OK, I am approving this, but is there really a fundamental reason we should not include cuco in the public space? (why yes for thrust but no for cuco?)

If later we move primitives and graph.hpp and graph_view.hpp (and few more files to create a graph/graph_view object) to a separate higher-level library, cuco should come back to the public space again.

Is this more of a temporary hack or we should never reference cuco in the public space in the future?

[ChuckHastings]

Fair question.

Anything we reference in the public API needs to be installed on the machine in order for someone to use our software as a C/C++ library. If a developer writes code and includes <cugraph/graph.hpp> or some other header from our library, then anything referenced in that header file needs to be installed. The smaller the list of requirements the easier it is for someone to compile with our code.

Obviously if they want to compile our code they will need all of our build-time dependencies. But if they install our code (say from conda) and then try and build, it would be nice to minimize the external things that we require them to have.

I'm inclined to say thrust might be a reasonable target to consider removing, since I don't think we use thrust across what I think of as our public API. I'm inclined to say that raft and rmm are going to be required, since we will want the raft::device_span and the rmm::device_uvector as inputs and outputs (respectively) of our functions.

I believe the primary motivation (from the scikit-build perspective) of removing dependency on cuco but not thrust is that thrust is already a requirement of other libraries, so it's not a burden.

[ChuckHastings]

@gpucibot merge

[vyasr]

To clarify the current issue a little bit, the problem is that in the current setup cuco is in a hybrid state:

• get_cuco.cmake does not include it in the INSTALL_EXPORT_SET, only the BUILD_EXPORT_SET, and it sets EXCLUDE_FROM_ALL=TRUE. That is how it should be treated if it were a private dependency, i.e. if it is required for building libcugraph but not for other libraries to build against libcugraph.
• cpp/CMakeLists.txt, on the other hand, says that cuco is a public link dependency. That means that any library building against libcugraph is going to try to find cuco, but it won't succeed because libcugraph didn't actually install it.

The upshot is that any library building against libcugraph is going to think that it needs cuco, even though it actually doesn't. That applies to the Python build with scikit-build, but also any other CMake-based build that has libcugraph as a dependency. That leaves two solutions:

1. Actually install cuco as part of the libcugraph build. This is probably the long-term solution.
2. Remove cuco from the public APIs. That's the solution employed here, which is simpler in the short term. In addition to the changes in this PR, that will also require removing cuco from the parts of the CMake build where it's exposed as a public link dependency. I'm working on that in Make cuco a private dependency and leverage rapids-cmake #2432.

We can probably aim for 1 in the long term, but 2 is the expedient solution to enable scikit-build for cugraph Python.