[HOpenGL] HOpenGL1.2 configure on cygwin & a GLUT scheduling question

[C.Reinke]

had to upgrade from ghc-5.02.2 to ghc-5.02.3 because of an access
violation bug, and ghc upgrades "naturally" mean HOpenGL rebuilds..

1. there's a slight problem with HOpenGL's configure on cygwin:

  GreenCard installs (as expected) in c:/Program\ Files/GreenCard/
  (note the space), and is found there by configure. By default, 
  however, configure seems to lose the escape for the space in the 
  path, so I explicitly give the path as something like:

    ./configure -with-green-card=c:/Program\\\ Files/GreenCard/green-card.exe

  That kind of works, but for the test for GreenCard's comma bug,
  where the executable isn't found, which configure then misinterprets
  by setting ..bug="yes", which then leads to errors while GreenCarding
  in make depend. 

  I used to think I understood shell escapes, but that was long ago,
  and this one has me baffled for the moment - the value of $green_card 
  in configure seems ok when echoed, and cygwin's bash can find the
  GreenCard executable with the path echo gives for $green_card, but 
  when configure tries to call $green_card, it fails to find the 
  executable (quite unlike later calls during make depend)..

  For the moment, I override the result of the GreenCard comma
  bug test to "no", and things seem to work okay, but there has
  to be a better way to set this right..

  An annoying new feature are lots of warnings whenever I compile 
  any HOpenGL stuff, of the kind:

    Module `GL_BeginEnd' is located in package `Main'
    but its interface file claims it is part of package `HOpenGL'

  This is easily rectified by doing make install, and the ghc
  package option is really nice, so I won't complain;-) but what
  about people who don't have permission to install the package
  by adding to ghc's imports? Is it possible to have local packages
  with central ghc installations?

  Apart from that, nice work!-)


2. What, if anything, do we know about the scheduling of the 
   GLUT callbacks?

  Thanks to GLUT's per-thread system, there seems to be only
  one OS-thread doing all the GLUT/GLU/GL-code for a given window
  (?), which translates into a single Haskell thread in ghc's
  (current) default configuration.

  Can I assume that callbacks will always run to completion, or 
  could keyboard input or redraws come in during a call to display 
  (and potentially trigger a redisplay before the old one has run 
  through?). What about stuff in idleFunc?

Claus