[HOpenGL] HOpenGL-1.01 Feedback

[Sven Panne]

[ Sigbjorn, Reuben: I've put you onto the CC: because you seem to be
  the WinDoze grandmasters for some fptools stuff... :-]

Andre W B Furtado wrote:
> Ok, here is my installing feedback about the "HOpenGL-1.01
> compatibility release pack for GHC-5.02":

Thanks for the quick feedback! I tried it yesterday under cygwin, too.
The first problem I've encountered is GreenCard versionitis: The
InstallShield version available via http://haskell.org/greencard/ is
quite old and broken beyond a point which autoconf could detect and
fix. So the first step was to compile GreenCard from source, but again,
some helping hand was required to build from the source tar ball with
ghc-5.02:

   rm src/{Pretty,FiniteMap,GetOpt}.lhs
   make HC="ghc -package lang"

Sigbjorn: Could you please update the InstallShield version to the latest
sources?

> [...]
> C:\WINDOWS\TEMP\ghc-476717.hc:4: GL/glut.h: No such file or directory
> 
> The solution I used was replacing all "-#include <GL/glut.h>" by the
> absolute path of glut.h (in my case, "-#include <c:/usr/include/GL/glut.h>")
> in the HOpenGL files. That worked fine, but why did it happen?

*sigh* ghc-5.02 comes with mingw, which is fine, but alas, mingw's headers
are not complete: The PATH_TO_5.02\include\mingw\GL subdirectory is missing,
although the corresponding libs are there. You can fix that by copying cygwin's
/usr/include/GL subdirectory.

Reuben (or whoever is in charge of the WinDoze versions of GHC): Could you
please fix that in the upcoming InstallShield versions?

> During the "make" step, I got a LOT of warnings like:
> 
> * Warning: Defined but not used: [...]

This is caused by GreenCard's inability to specify which (un)marshaling
function is not needed => harmless.

> * C:\WINDOWS\TEMP\ghc-432219.hc:71: warning: assignment discards qualifiers
> from pointer target type [...]

This is caused by the FFI's inability to specify which pointers are const.
Some proposals were already made on the FFI list, but IIRC there was no
consensus (which is a pity BTW! We should sometimes be a little bit more
pragmatic there...). Again, this is harmless, at least for language bindings
which rely on C. With C++, the corresponding function/method would not be
found due to name mangling. (<= *hint* to the FFI people :-)

> After all the compilation process, when I tryied to run "hello.exe", I got
> the following messages in cygwin:

Hmmm, I'm a bit surprised that you came that far. I had to inline some
GLU constants in GLU_Quadrics, GLU_NURBS, and GLU_Tess, because of GLU
versionitis. >:-( Perhaps another cygwin version? I've downloaded mine
a few days ago. Strange. I'll have to do something about that...

> [ DLL hell deleted ]

What linker options did your configure run determine? The only thing I had
to do was to copy cygwin's /usr/bin/glut32.dll where your exe would find
it. e.g. in the corresponding examples dir or windows\system. This is not
surprising after all, because WinDoze doesn't come with GLUT.

opengl32/glu32 vs. opengl/glu is a different story: You should always link
against the more recent *32 versions, otherwise you probably won't get
any hardware acceleration at all. Perhaps you should send me configure's
log. BTW, if you don't have the *32 stuff, the self-extracting ZIP at

   ftp://ftp.microsoft.com/softlib/mslfiles/opengl95.exe

is the way to go...

Cheers,
   S.