GHC and Win32 API - help wanted
A while ago (in connection with HGL problems, some of which were traced to incorrect greencard output), I asked here:
Alternatively, is anyone out there using ghc's win32 binding?
As noone has responded so far, I have to conclude that this is quite an infrequently used package.. - noone using ghc + win32 API? - noone using ghc + hgl on windows? Alastair provided updated greencard outputs for win32, but neither he nor I tend to build ghc from source on our windows machines, and I found it non-obvious how to build hslibs/win32 from cvs in isolation (without building most everything else), so I asked here:
I still have to figure out how to make hslibs/win32 in isolation, so I won't be able to test & confirm whether this solves all the HGL/GHC/Win32 problems for a while (e.g., there was the problem of polygon creation running out of resources, see Friday's email; that could easily be related to the same ffi problem, but it would be good to check) - anyone else in a better position for testing?
Again, no response, so I have to conclude that either noone is
building ghc from cvs on windows here, or none of those who do
have any interest in HGL.. no users, no testers:-(
We suspect that Alastairs fixes may still leave some issues with
concurrency / potentially blocking threads / ffi (at least in GHC's
default configuration on windows), but we'd like to see just how far
the improvements go, as the next stable release of GHC is imminent.
* Could anyone with cvs/fptools/makefile-expertise lend me a hand
* if I try again to build only hslibs/win32 from cvs? Or is it
* completely unreasonable to expect this to work?
The fresh greencard output seems to depend on parts of the ffi
syntax that weren't supported in ghc-5.02.2, so I'd have to try with
ghc-5.03.20020208 (the latest windows installer snapshot).
Here's what I've got now, re-configured for the new ghc version:
- checked out cvs sources
- cd fptools; autoconf; configure --with-ghc=ghc-5.03....
- create mk/build.mk:
GHC_INPLACE = $(GHC)
GHC_PKG_INPLACE = echo 'GHC_PKG_INPLACE'
- cd hslibs/win32
$ make
gcc -E -undef -traditional -I../../ghc/includes -x c win32.conf.in \
| sed 's/^#.*$//g' >win32.conf.inplace
win32.conf.in:1: config.h: No such file or directory
gcc -E -undef -traditional -I../../ghc/includes -DINSTALLING -x c win32.conf.in \
| sed 's/^#.*$//g' >win32.conf.installed
win32.conf.in:1: config.h: No such file or directory
../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package
Hi Claus. Moral support but little else below....
As noone has responded so far, I have to conclude that this is quite an infrequently used package..
- noone using ghc + win32 API? - noone using ghc + hgl on windows?
Although I feel the Win32 package is important I am finding it impossible to build GHC from CVS in order to debug my main project which, (unfortunately for your own interest in HGL), uses ObjectIO, so I felt that I was unable to offer anything coherent to you. I can't even get as far as the Win32 library while building GHC from scratch at the moment.
We suspect that Alastairs fixes may still leave some issues with concurrency / potentially blocking threads / ffi (at least in GHC's default configuration on windows), but we'd like to see just how far the improvements go, as the next stable release of GHC is imminent.
I suspect that the problems I had with profiling the ObjectIO library recently reported on the bugs list are also caused by thread issues, but I can't test this hypothesis due to the problems outlined above.
* Could anyone with cvs/fptools/makefile-expertise lend me a hand * if I try again to build only hslibs/win32 from cvs? Or is it * completely unreasonable to expect this to work?
The fresh greencard output seems to depend on parts of the ffi syntax that weren't supported in ghc-5.02.2, so I'd have to try with ghc-5.03.20020208 (the latest windows installer snapshot).
When I tried building CVS GHC with this package I got a compiler which would not work.
But if I try setting GHC_PKG_INPLACE today, there's absolutely no change! The setting in fptools/mk/build.mk seems to be ignored now?
Yes, I haven't found a way of getting around this problem myself other than hard wiring the compiler (possibly in target.mk from memory?)
Any helpful souls out there, who could lead me through the jungle of bewildering makefiles tomorrow (target date for feature completeness for the next release)?
Sorry not to be of more help.
If not, I'll just drop the issue (those who reported the problem earlier seem to have given up? and Simon Thompson, who last ran into it, does now get acceptable performance from Hugs/HGL for his app).
Lost, Claus
Even more lost, Mike Thomas.
participants (2)
-
C.Reinke -
Mike Thomas