Detour needs a C API

[GoogleCodeExporter]

Detour's presently all C++, which is great when linking statically with other 
C++ projects, but a little painful if you're trying to use it through a DLL or 
from other languages (such as .NET through P/Invoke).

What would ease this would be a simple C wrapper around the C++ API. Very 
formulaic; just a bunch of free functions that look like:

dtStatus dtNavMeshQuery_init(dtNavMeshQuery* query, const dtNavMesh* nav, const 
int maxNodes) { return query->init(nav, maxNodes); }

These functions can then all be marked __declspec(dllexport) and extern "C" {}, 
making them available if the code is built as a DLL.

Original issue reported on code.google.com by richard....@gmail.com on 8 Dec 2010 at 9:27

[GoogleCodeExporter]

To start things off, here's a simple patch that wraps all the allocation 
functions in extern "C" {} blocks.

Original comment by richard....@gmail.com on 8 Dec 2010 at 10:13

Attachments:

• extern-c.patch

[GoogleCodeExporter]

Here's a .cpp file that, when built with the rest of the code in a DLL project, 
should export the NavMesh, NavMeshQuery and QueryFilter class functions in a 
C-callable manner.

I generated it using SWIG and a really yucky XSLT that I wrote, also attached...

Original comment by richard....@gmail.com on 9 Dec 2010 at 12:03

Attachments:

• c_api.cpp
• detour_swig.i
• generate_c_api.xslt

[GoogleCodeExporter]

I generally agree on C API. What I'm worried about is how to keep it up to date 
and how to make it compile on win/mac/linux (I don't think 
__declspec(dllexport) is not portable).

I'm currently struggling to keep all the version up to date since I don't have 
a linux box or windows machine to test on.

Ideally I would like someone else to maintain and support the C API. I wish I 
could the same for win32 projects and linux make files too :)

What is that xslt used for?

Original comment by memono...@gmail.com on 9 Dec 2010 at 8:29

[GoogleCodeExporter]

The XSLT is used to transform the output from SWIG into C, as SWIG's built-in 
support for C is not yet released. That's how I propose keeping it up to date: 
have it be automatically generated by using SWIG and MSXML, as an automatic 
build step. The XSLT is yucky because I've put in a load of stuff for working 
around bugs in SWIG's handling of the C++ type system and for filtering out 
classes/methods that we don't want to expose in a C API.

I can have a crack at writing up the necessary build scripts, if you like - I 
can give you VC++ 2010 project files too, if you want, though I appreciate that 
maybe you don't want to do that if they're going to get out of date. (Or I can 
write a Mac-compatible script that generates a VC++ 2010 project file :D).

Original comment by richard....@gmail.com on 9 Dec 2010 at 2:14

[GoogleCodeExporter]

Hi,

Now that Christmas is finally over and I have been able to flush my most urgen 
todo list, I'd like to find a solution to this.

Ideally I would like to have a script which I could run before I make a commit 
which would do all the magic. Supporting all the features and platforms is my 
biggest bottleneck currently.

Also, I would like to (eventually) include Recast C API too for the sake of 
completion. The debug draw stuff is super valuable, so ideally I would like to 
have that too. And a cheeseburger, please! ;) I'm not sure how a virtual 
interface (duDebugDraw) would look through C API, though.

Are there any nasty things in the C++ APIs which I could fix to make the C API 
easier to build?

Original comment by memono...@gmail.com on 3 Feb 2011 at 10:14

• Changed state: Accepted

[GoogleCodeExporter]

Welcome back, hope you had a good Christmas.

As far as Detour is concerned, the only nontrivial bit I can think of is the 
virtual function stuff in dtQueryFilter. It'll still be very useful for C 
clients to provide their own passFilter/getCost implementations, but they'll 
have to do them as free-standing function pointers. I don't think this'd be too 
hard to arrange - create a subclass of dtQueryFilter that forwards to the 
function pointers - though there might be a more efficient way...

Everything else maps fairly neatly to an 'explicit this' idiom, i.e. 
dtNavMesh_method(dtNavMesh* self, ...)

From a script point of view, my SWIG approach is very overcomplicated (I was 
mostly trying to avoid changing any of your code, to make upgrades easy). It 
should be possible to tag all appropriate method declarations with CAPI or 
something, and then grab and parse them with a bit of regexp magic. I'll have a 
look at this once I've got some time, if you like.

Original comment by richard....@gmail.com on 9 Feb 2011 at 9:48

[GoogleCodeExporter]

Hi!

I'm interested in using detour as a DLL. Has any progress been made on the 
ideas mentioned in this issue? If not, are you still interested in having 
something that works as described in the 5th comment ?:

"Ideally I would like to have a script which I could run before I make a commit 
which would do all the magic. Supporting all the features and platforms is my 
biggest bottleneck currently.

Also, I would like to (eventually) include Recast C API too for the sake of 
completion. The debug draw stuff is super valuable, so ideally I would like to 
have that too. And a cheeseburger, please! ;)"

Have a great week-end!

Original comment by julien.g...@gmail.com on 1 Oct 2011 at 2:29

[GoogleCodeExporter]

We only have ponies, is that ok? ;)

I have not had enough time to look into this. If someone wants to take a stab 
at it, I'm willing to include patches, etc. Unfortunately I don't have enough 
time to look into the C API and to maintain it for all the platforms.

--mikko

Original comment by memono...@gmail.com on 1 Oct 2011 at 4:11

[GoogleCodeExporter]

Alright, thank you very much for your answer. I will look into it and maybe 
I'll be able to find some time to do it.

Original comment by julien.g...@gmail.com on 3 Oct 2011 at 12:50

[GoogleCodeExporter]

For the time being, could we get the dtAlloc*/dtFree* functions (i.e. 
dtAllocNavMesh/dtFreeNavMesh, dtAllocNavMeshQuery/dtFreeNavMeshQuery, etc) 
wrapped in 'extern "C"' blocks? I expect they'd end up being exposed as part of 
a C API in their present form anyway, so once they're wrapped in those blocks 
they're good to go. 

For now I just have to remember to keep patching them every time I pull the 
latest code, but it would be nice if I didn't have to do that ;-)

Original comment by richard....@gmail.com on 30 Mar 2012 at 11:27

[GoogleCodeExporter]

Can you post me a patch so that I definitely get it right?

Original comment by memono...@gmail.com on 1 Apr 2012 at 9:46

[GoogleCodeExporter]

Sure, here it is; but I'm using recastnavigation via Git, so the patch file 
format may not be compatible with your tools. I'm not sure how to apply it 
directly to SVN, short of getting the SVN toolkit and checking out a fresh copy 
of the codebase and making the changes again.

Original comment by richard....@gmail.com on 2 Apr 2012 at 1:48

Attachments:

• 0001-C-linkage-for-global-standalone-functions-in-Detour.patch