Cuml: [TRACKER] Support for native C++ interface

[teju85]

Is your feature request related to a problem? Please describe.
We need a solid, native, C++ API exposed via cuML, just like the one proposed by @jrhemstad here: https://github.com/rapidsai/cudf/issues/1027. Read the next section for details...

Describe the solution you'd like

1. Use templates, classes, as per your needs for everything that's NOT exposed outside of cuML. This also means, all of ml-prims can be header-only.
2. For the ones to be exposed to cython (or any C++-aware trans-compiler), explicitly instantiate those. 2a. This should mean, to pass on the throwing of exceptions as well. Because it is greatly helpful in error handling, especially in cython side.
   2b. There might be a way to handle templated c++ codes in cython, but having cython call in to the C++ tooling, especially cuda toolkit is not that great!
3. Later, when we get to exposing C wrapper, we mostly need to convert those exceptions to some sort of error codes. (maybe cumlError_t?)

We'll now have 2 .so files supported:

1. libcuml++.so: which exposes the aforementioned C++ API.
2. libcuml.so: which exposes the above mentioned C wrapper API.

Tagging all who were part of the initial discussion: @jrhemstad @jirikraus @dantegd @cjnolet

[teju85]

There's a potential issue with ABI, especially with deploying libcuml++.so. However, we could work-around it with C++11 ABI OFF to ON. (suggestion by @jrhemstad )

[jirikraus]

I agree that the cuML implementation should converge to modern C++ code, which to my under standing point 1 implicitly states. Regarding an external C++ interface for cuML I think it should follow a traditional header + lib approach as you suggest. One reason I see is that cuML is used potentially used from various languages: Python, C++, C, .... so we need a compiled libcuml.so anyway. The alternative of offering a header only C++ external interface will cause confusion, possibly link errors due to duplicated symbols and cause longer compile times due to redundant complication.

[jrhemstad]

Regarding an external C++ interface for cuML I think it should follow a traditional header + lib approach as you suggest. One reason I see is that cuML is used potentially used from various languages: Python, C++, C, .... so we need a compiled libcuml.so anyway.

Agreed.

I think a "header-only" cuML library would confuse more than help the situation. There needs to be a precompiled library with the C++ symbols available to those who can consume a C++ API directly.

For those unable to consume C++ symbols, the C API will be available.

[dantegd]

@teju85 I did not mean to close this at all, closed it accidentally while at my phone

[teju85]

The first task of libcuml++.so build has been complete now. However, the proper C-build into libcuml.so is missing. @muellren wants this for his application which is C-only and having a libcuml.so would simplify his workflow.

[muellren]

I am currently only using dbscan and both fp64 and fp32 variants are available as C exports in libcuml++.so already. I assume that once libcuml.so becomes available those will be moved over.

[teju85]

With the merge of #375 and #641, we now have a proper C++ shared lib as well as a wrapper C shared lib getting built as part of our build process. Thus, closing this issue.