[FEA] cuML to expose a "proper" C-API

[teju85]

Is your feature request related to a problem? Please describe.
Currently, we directly expose underlying C++ implementations via cython. Since cython can also understand C++ interfaces, all is well for us. But if we need wider adoption, I think we should expose a true C-API (for eg: declaring symbols under "extern C"). Such an interface can then be easily usable across multiple languages.

Describe the solution you'd like
As a first step, we could just start by wrapping our *_c.h files under each algo folder of cuML with "extern C" declarations.

Describe alternatives you've considered
-NA-

Additional context
None.

[dantegd]

Given that we are doing that *_.c.h approach for all current (and immediately imminent) algorithms, what would you say would be the ideal long term solution beyond wrapping them in extern declarations?

Also tagging @datametrician

[datametrician]

I think the only long term solution is wrapping them in *_c.h, and we would welcome anyone to do that. That said, given our current workload, this isn't a priority instead of getting more algorithms out with a C++ API and python bindings.

If any user who needs a C API would like to do this for RAPIDS I would be very happy.

[teju85]

My main aim for filing this issue was to make sure that over the course of things, we will be able to support other languages wrapping around the core of cuML. I wasn't also requesting for prioritizing this one. But making sure that this doesn't slip through the cracks.

Apart from 'extern', I can't think of other things, right now. I'll update this issue, if I remember anything else.

[teju85]

Issue #248 briefly discusses the C-API. I believe once we have a proper native C++ API. We should only then try to plan for and implement this.

[datametrician]

I agree, let's close this in favor of #248. I think this is lower priority than a native C++ API.