- added GL/glut.h Perhaps a patchlevel-only release would be the right thing.
patchlevel-only intermediate releases! great idea! I second your suggestion! .. oh, wait a minute, that was my suggestion, so I may just be a bit partial;-) but seriously, that would help potential users a lot: no need to worry whether they made mistakes with patches - just download one package, build it, and if anything goes wrong, don't be quiet, just send an email to this list. it would also save you the trouble of explaining whether HOpenGL-1.xx is a bugfix-release or adds/changes features: bugfixes just bump the patchlevel, feature changes bump the release number.
But I'm not sure how I can include this file in it, it must be placed where GHC's MinGW C compiler will find it...
as this seems to be a windows-binary issue only, with files missing for a limited number of ghc-versions, and cygwin assumed for installation, one could check for the contents of `ghc --print-libdir`/include/mingw/GL/, and add whatever is missing? in general, this seems to be an example of functionality that needs to be in the standardized compiler/interpreter API ("my project needs include files, where do I need to put them?"), if the library infrastructure idea is to have any chance. I hope you and Alastair are making sure that whatever comes out of that effort is sufficient to build your projects?
- replaced evil hack with "ghc --print-libdir" Hmmm, older GHCs don't have this option IIRC.
well, for those older versions your hack apparently worked, whereas for new versions the situation is reversed. sounds like a job for configure?
Compiling Main ( Boids.hs, obj/Boids.o ) Linking ... c:/ghc/ghc-6.0.1/libHOpenGL.a(GL_Marshal__1.o)(.text+0x28):ghc2444.hc: undefined reference to `__stginit_CString_' c:/ghc/ghc-6.0.1/libHOpenGL.a(GL_Texturing__1.o)(.text+0x5a):ghc2844.hc: undefin ed reference to `__stginit_List_' c:/ghc/ghc-6.0.1/libHOpenGL.a(GL_BasicTypes__1.o)(.text+0x1e):ghc2944.hc: undefi ned reference to `__stginit_Bits_' make: *** [Boids] Error 1
Further suggestions?-)
Oh, well... The old libraries are a moving (and sometimes vanishing) target nowadays. :-P Could you try the following patch and tell me if it works for you?
yes, adding haskell98 to package_deps seems to do the trick. does the infrastructure project address these issues (libraries in motion and how to avoid motion-sickness in future)? Thanks for the quick help, Claus