[PD-dev] [GEM] GEM CVS... x-platform issues

[Daniel Heckenberg]

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