Hi GEM developers,
I've recently (finally!) worked to make the CVS version of GEM actually build and run under Windows. There's lots of exciting new stuff in there which is good to see. The real-time graph updating is certainly an improvement.
Tweaking GEM to build was not a particularly difficult experience but there are a few little issues that may bite (mainly caused by deficiencies in Windows and VC++ I might add). For the time being, I'll keep fiddling with others' source changes in such a way to make them build under Windows without breaking them on other platforms. Apologies in advance if I do, however, wreak havoc. Here are a couple of the issues if you want to try to avoid them...
1) Problem: 'for' scoping for VC++ 6.0 isn't compatible with the "new ISO" style scoping that GCC seems to support/default to.
E.g. for (int i=0; i < i_max; i++) func(i); for (int I=0; i < i_MAX; i++) // causes VC++ redefinition error func2(i);
Short-term Solution: I just removed any variable redefinitions that caused compiler errors under VC++. This may now result in warnings on other platforms. This is undesirable and I don't want to suggest that the code should conform to VC++ non-conformance...
Long-term Solution: We probably should code to avoid both the VC++ error and the GCC warning.
2) Problem: Windows needs to have <windows.h> explicitly included before many of the "platform independent" GL headers (e.g. gl.h, glu.h etc).
Short-term Solution: I added the #ifdef _WINDOWS etc. inclusion of windows.h wherever it's need... including the "I hate windows, I shouldn't have to do this". Whose immortal words are those, anyway?!
Long-term Solution: I'll see if it's easy to add windows.h as a default include somehow so we can avoid pollution of the GEM source. OTOH, this causes a bit of obfuscation and "make" builds would be complicated....
That's enough for now, Daniel