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 <win32.conf.inplace
../../ghc/utils/ghc-pkg/ghc-pkg-inplace: not found
make: *** [all] Error 127
I don't really see why a simple make should start installing things,
even if it's just package configurations, so in my first attempt, a
few days ago, I just replaced set GHC_PKG_INPLACE to a dummy (in
fptools/mk/build.mk), and got on to the next problem (a
splitting-object-file headache, iirc). Alternatively, if this is
necessary to keep the installed win32 package from messing things up
during the build (how could it??), I could re-route that to use the
installed ghc-pkg?
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?
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)?
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