[ODE] Cylinder-cylinder collison bug?

[John Miles]

You don't really need a script.  Ideally, the msvcdefs.def file would go
away entirely in favor of properly decorating all exported functions and
variables with __declspec(dllexport).  What a Win32 implementation would
normally do is add a /DBUILDING_ODE flag to the cl compiler line when
building the library (but not the example programs in the test directory),
then have all of the ODE header files do a

#ifdef BUILDING_ODE
#define ODEX __declspec(dllexport)	// ODE is including the header
#else
#define ODEX __declspec(dllimport) 	// App is including the header
#endif

If you do that, and include a __declspec(dllexport) on all of the exported
function and variable definitions in the C files that implement them, you
don't need a .def file, and the functions that are present in your
particular build will be exported automatically.

I started down this path with my Win32 build, but decided it wasn't worth
the trouble as long as the rest of the Byzantine build procedure is in
place. :)  It works fine either way, of course, as long as you're careful
not to accidentally declare local copies of exported variables in the header
files when they're compiled by the application.

-- jm

> JM> Thanks, Adam.  Unfortunately, I just spotted another
> equally-glaring bug
> JM> right above this one, at line 1105:
> JM> dGeomCylinderGetParams(o1,&cylRadius1,&cylLength1);
> JM> dGeomCylinderGetParams(o1 /* should be o2 */,&cylRadius2,&cylLength2);
>
> I've just noticed that this has not yet been commited to the cvs, i hope
> it wont be forgoten :)

Good point...

> Could someone maybe also update the msvcdefs.def file. It's pretty
> outdated and a bunch of new functions have appeared since then.
> I'm including the .def file i use, i think it's pretty complete.
> Isnt there a script or something that could extract each exported
> function from the code and build the .def file automaticaly ?
>