| * 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 --------------------------------^^^^ (only)

a) No it is not unreasonable to expect it to build, cleanly, starting from scratch. It jolly well ought to.

Ah, but (perhaps unlike Mike) I don't want to build from scratch, but *only* the hslibs/win32 directory. For older packages like win32, there is no inherent reason why it should need to be build with a freshly-built ghc by default (although ffi-bindings rule out older ghcs), and there are lots of extra things that can go wrong when one tries to build ghc from sources. Not that those new problems couldn't be sorted as well, with some further recursive levels of debugging, but that's far away from the original problem.. To wit, here's recursive story so far: user1: I'd like to compile my hgl project with ghc on windows, but it doesn't work user2: I can reproduce the effects, one of the problems seems to be in a call to the win32 api that behaves differently using hugs or ghc user3: yes, there was a problem with greencard's output, greencard is now fixed user2: is that the released greencard? user3: no, only cvs user2: how do I get an updated win32 package? user3: it's only in cvs user4: but the cvs win32 sources are no longer regenerated automatically user3: I've regreencarded the win32 sources in cvs, but I can't test that here, so that may not make it into the next release user2: I could try testing them here. how do I make only the hslibs/win32 package, without building everything? user5: you don't - you always build ghc from source first, then build the package with the freshly-built ghc; or rather: you build lots of packages, one of which is the one you want.. user2: sigh.. I don't really want that.. but let's see.. user2: ..what is this odd effect?.. ... It should be easy to see that this makes it harder than necessary for cvs-outsiders to contribute anything small, such as an offer to test a change on their system. May I suggest to have, either as part of the local Makefiles, or at least as a separate ascii file, the information about which version of ghc is minimally needed to build each package? Given that the package.conf-files already record dependencies, that may be a good place to put this info (just checking... no, they don't seem to do that yet, not even a package version number?). That would go some way towards a more modular system.

b) I strongly recommend that you build it by checking out fptools/mk, glafp-utils (you get these with fpconfig) fptools/ghc, libraries, hslibs

Then build GHC, using practically any installed GHC (later than about 4.02 I think). Then build 'libraries'. Then build 'hslibs', which includes win32.

But libraries and hslibs include lots of other stuff as well, most of which is a lot bigger than win32, and unlikely to be needed in newest form just to rebuild win32. That is a lot of extra time in downloading and building, and a lot more room for new problems. At least the unnecessary building should be avoidable (that's what Makefiles are used for, no?).

The point here is that we update 'libraries' and 'hslibs' to track the GHC in the tree, so there's no guarantee that it'll work if you compile it with some older GHC. It may, but it may not.

But cvs contributors should know whether or not they need to bump up the needs-ghc-version-x number in a package to make their changes build?

c) I use the standard build.mk (build.mk.sample). I don't try to install anything, at least not to start with. Just say use the standard build.mk (or even an empty one) and say 'make'.

I did this today, and happily built a HSwin32.o package from scratch.

Great, so perhaps you could check quickly whether that solves some of the HGL problems?-) HGL is in hslibs/graphics, which you've just built anyway, or you could use Sigbjorn's nice msi-package from the Hugs download page. Then take the following small example file: import GraphicsUtils main = runGraphics $ do w <- openWindow "testing" (200,200) drawInWindow w $ text (100,100) "1,2,3" drawInWindow w $ polygon [(50,50),(100,100),(50,100)] getKey w closeWindow w and compile with something like: ghc --make -i<path to your graphics bundle>/lib/win32 --package concurrent --package win32 example.hs If the result runs without error (using your newly-built win32 package), things have improved a lot. If there's an error about Polygon and storage, there's still something unexpected wrong, but if you comment out the second "drawInWindow"-line, the program should run, and the window should be of reasonable size (not a full-screen titlebar-only thing, as with the current version of win32). It may still have to be stopped with ctrl-c, but that would be enough improvement to suggest that Alastair's changes should be included in the upcoming ghc. Given this simple test, you'll agree that having to compile ghc and objectIO and ... from CVS just to get there is somewhat unexpected (of course, you might wonder whether having to install HGL is an expected side-effect of your own email;-). Sorry to be so obstinate, Claus PS. Just to show that I'm a good netizen, I've tried what you suggested. The problems are unlikely to be big, but I'm not tempted to follow the recursion any deeper (for the usual reasons: work is waiting): cvs co fpconfig cd fptools; cvs co ghc libraries hslibs autoconf; cd ghc; autoconf; cd .. configure configure: error: Happy version 1.13 or later is required to compile GHC. [delete exit in configure's happy test] configure cd ghc make $ cd ghc Administrator@CR3-PC /tmp/tmp/fptools/ghc $ make ------------------------------------------------------------------------ ===fptools== Recursively making `all' in includes utils driver docs compiler rts ... PWD = /tmp/tmp/fptools/ghc ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make all - --unix -r; in /tmp/tmp/fptools/ghc/includes ------------------------------------------------------------------------ Creating config.h... Done. gcc -O -c mkDerivedConstants.c -o mkDerivedConstants.o In file included from Rts.h:20, from mkDerivedConstants.c:10: Stg.h:210: gmp.h: No such file or directory make[1]: *** [mkDerivedConstants.o] Error 1 make: *** [all] Error 1 $ uname -a CYGWIN_NT-5.0 CR3-PC 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown $ ghc --version The Glorious Glasgow Haskell Compilation System, version 5.02.2