Build path for MSVC/Windows.

[slembcke]

So some sort well supported of build path for Windows has been long in the tooth. While I'm rather happy with my decision to use C99, it seems to cause Windows programmers a good deal of trouble.

As I see it the options are something like the following:

• Compile as ISO C under using MSVC. Requires significant readability downgrades to my C99 code.
• Compile as C++ under MSVC. Looks like it would require fewer changes, but still not simple.
• Compile using GCC. My favorite option as I don't have to do anything. MSVC users would only get a binary to work with.

I know several people have successfully attempted this in all three ways. I've even had people send me their code, but in those couple of cases it's been changed so heavily that I'm not sure what to do with it. I can no longer compile it and am unsure where to add in #defines or #ifdefs to make things happy. Is there a simple way to accomplish the first two without requiring changes that would require significant changes to my C99 code?

Also, as I do not own a Windows machine, is there anyone who would be willing to take responsibility of the Windows build?

[Michael Buckley]

I second the vote for the third option. Not only is it the easiest option, but it keeps the benefits of of the C99 code for the platforms that support it. It is rather sad that, despite being standardized in 1999/2000, that it still has so little support. In fact, the toughest sticking point my team faced when it decided whether or not to adopt Chipmunk was that the C99 features would limit the platforms the game would be portable to. Not that we were planning on porting the game to more than OS X/Windows/Linux/BSD, but since we were going with pretty standard C code, it would have been trivial to port it to, for example, the DS or PSP.

Although I have next to no experience with MSVC, Chipmunk compiles without any changes under MinGW. Unfortunately, the MinGW DLL files are not compatible with the MSVC DLL files. Using MSVC's lib.exe cool, it is possible to create a chipmunk.lib which, I have been told, will allow the MSVC project to statically link to the MinGW dll. What I am not sure of, however, is whether this allows the DLL to be used with other languages, such as C#, which I am told that DLLs compiled with MSVC can do.

I may be wrong on some of the details, as I am not a Windows person. I do know that Chipmunk compiles without any changes using MinGW, and that the DLL files are not compatible across compilers.

[extralongpants]

I put together a VS2005 project for chipmunk a while back. I wouldn't call it a trivial task; I think it took me around 3 hours to get the library compiling cleanly.

I'm sure you could come up with a list of simple guidelines to follow to make sure the library is at least close to compile-able under MSVC, but I'm not sure if it's worth the effort, especially if you don't have direct access to a Windows machine.

I think your best bet for now would be to find some one who can compile the binaries for Windows using gcc at every major release, and to give up on maintaining a Visual Studio project.

[EDIT] - I don't know if I've ever tried using non-MSVC-built libs in an MSVC project, so I can't really comment on that bit.

-Chris

[Michael Buckley]

I did not have a lot of time at work today, but I did try to create a chipmunk.lib file from the MingGW chipmunk.dll, using information found on the MinGW site. While this worked, when I attempted to compile the moon buggy demo sing the MSVC command-line tool cl.exe, it ha trouble with chipmunk.h, and possibly others (cl.exe stops giving warnings and errors after 100). I am not very familiar with MSVC, but it seems that even if we can produce a DLL which MSVC can use, it will be useless unless MSVC can read the header files. It seemed to be having a lot of trouble with the inline keyword, but there were probably other problems as well.

Has anyone who has compiled Chipmunk with MSVC confirmed that the header files are not compatible with MSVC as-is?

[smg]

Yep, they're not compatible, but it's just about 20 minutes of work to get it running. Just let it compile as c++ code and fix the remaining compiler errors. Most of them are implicit casts, and some c99-only constructs, that need to be changed. It's really not that hard if you just read the compiler output.

[slembcke]

Yep, they're not compatible, but it's just about 20 minutes of work to get it running. Just let it compile as c++ code and fix the remaining compiler errors. Most of them are implicit casts, and some c99-only constructs, that need to be changed. It's really not that hard if you just read the compiler output.

Good to know. If I cleaned up the implicit casts (which is probably bad practice anyway) would that make things much more pleasant in MSVC land?

[smg]

Yes, that would probably make life much easier. The other problems were functions that return a struct, being initialized on return, like:

Code: Select all

static inline cpVect
cpv(const cpFloat x, const cpFloat y)
{
    return (cpVect){x, y};
}

I mean it looks nice and is totally readable, but c99-only. The following example shows a little more ugly, but MSVC friendlier Version. For my part, I just defined a constructor for those structs, but that won't probably work for the c99 standard.

Code: Select all

static inline cpVect
cpv(const cpFloat x, const cpFloat y)
{
    cpVect v={x,y};
    return v;
}

Ah, and i just remembered, that the math headers of MSVC don't define INFINITY, but i found this hack somewhere on the internet, that I placed on top of the chipmunk.h header :

Code: Select all

#ifndef INFINITY
//#define INFINITY (1.0f/0.0f)
union MSVC_EVIL_FLOAT_HACK
{
   unsigned __int8 Bytes[4];
   float Value;
};
static union MSVC_EVIL_FLOAT_HACK INFINITY_HACK = {{0x00, 0x00, 0x80, 0x7F}};
#define INFINITY (INFINITY_HACK.Value)
#endif

You also need to define _USE_MATH_DEFINES before including math.h, or else M_PI won't be defined. I think this should sum up most of the problems. Anyway, the engine is just awesome.

[Michael Buckley]

It's really not that hard if you just read the compiler output.

Yes, I figured as much, but before yesterday, I had absolutely no experience with MSVC, and I essentially had seven minutes to create the .lib from the .dll, and try to compile using cl.exe. All I did was:

cl *.c chipmunk.lib /I"..\..\include\chipmunk"

And it spat out 100 errors, and then told me that it had stopped displaying the errors after the 100th error. At that point, I was needed somewhere else, and I couldn't figure out how to copy and paste from cmd.exe.

So I think ultimately we're saying the same thing, in that it's not hard if you read the compiler output. I just simply didn't have the time.

Though I would like to assume that MSVC in C++ mode is compatible with plain C files, in practice, things do not usually turn out to be so easy. If I have written a game in C, but need to compile the chipmunk headers in C++, will this work? Or with MSVC users be forced to use C++ if they want to target MSVC, do they have to write their games in C++?

[slembcke]

The headers are wrapped as extern C, so it should work fine. The catch being any of the static inline functions that I've defined in the various headers. I remember someone changing everything to __inline, would a simple #ifdef macro work for that?

[dodecahedron]

The headers are wrapped as extern C, so it should work fine. The catch being any of the static inline functions that I've defined in the various headers. I remember someone changing everything to __inline, would a simple #ifdef macro work for that?

Yeah, this worked for me:

Code: Select all

#ifdef WINDOWS
   #define inline __inline
#endif

I was able to get everything running in MSVC2005 without too much trouble or uglification of the code. I might be willing to take responsibility for the Windows build. Let me play around some more next week, and if I decide to use Chipmunk in my current project, maybe we can work something out?