GHC and Win32 API - help wanted

[C.Reinke]

> |   * 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