On Sat, 2009-06-13 at 21:54 +0100, Francis Russell wrote: > > Sure, no problem. It sounds like you have something specific in mind -- > > and like you know the library better than I do. Would you be able to > > create a patch? > > I've only started using it recently, although I have noticed a few > issues of varying importance. To be honest, most of these should > probably be addressed upstream and having a divergent Debian version, > even if it is superior is probably a bad thing. Anyway, these are the > various issues: > > - no #ifdef header guards to prevent multiple inclusion. > - #define of REAL conflicts with other headers. In my case, the OpenMPI > ones. At the very least, making it a typedef might make the errors > easier to understand without damaging compatibility although I think > having such #defines for REAL and VOID is something to avoid. > - A #ifdef __cplusplus guarded extern "C" construct would be nice for > C++ users. > - The Debian-specific API exposure might cause issues. In my case, I had > classes/variables named triangle, mesh and vertex.
All excellent points, thanks! > I don't fully understand why so much of the triangle API was exposed. > Does OpenCASCADE depend upon Debian specific modifications? Would it > make more sense to put the extended API in a header which then includes > triangle.h? The original motivation was OpenCASCADE, but version 6.3 doesn't link to triangle at all, so that's no longer an issue. A second header is a good idea! > I'm happy to make any patches if you think some of these issues should > be addressed in the Debian version. I'd be happy to accept such patches for a new revision of the triangle Debian package. Thank you, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part