[nhc-bugs] Building nhc98 on Windows 2000

[Malcolm Wallace]

> 1) what exactly is "fullname" supposed to do in configure?
> 
>     if fullname 2>>/dev/null  # cope with symbolic links in directory

What it says in the comment... :-)  If `fullname' is available it
gives the absolute pathname to its argument, i.e. it expands symbolic
links fully in the directory part.

>   And where is it supposed to come from? I can't find it, and neither 
>   can configure:
> 
>     Updating targets/ix86-CYGWIN_NT-5.0/hmake3.config...
>     fullname: not found

If your system doesn't have it, it won't be executed.  You definitely
shouldn't see the `not found' message, because that was redirected to
/dev/null.

Curiously enough, the only reason I introduced `fullname' was because
of Cygwin.  Remember the business with $(PWD) vs $(shell pwd) in
Makefiles (Cygwin requires the latter)?  Well in Unix systems, the
two forms give different results if there are symbolic links in the
directory path.  Hence `fullpath' is used as a hack to try to patch
up the difference.

> 2) is this really the line you want to get (in MkConfig.hs:210)?
> 
>     $ grep 'NHC98INCDIR' /tmp/nhc98-1.12/script/nhc98 | cut -c27-
>       | cut -d'}' -f1 | head -1

No, and if you look closely it isn't the line I wrote either... :-)
It actually reads
      $ grep '^NHC98INCDIR' ...

> 3) after telling hmake-config not to bother with ghc, the case of
>    the failing write to /tmp/.. appears to be in the second call
>    to runAndReadStdout in MkConfig.hs (see 2), and all those calls 
>    use the same tmpfile for output from "system" calls. If the
>    "grep" is the second call, that means that one call has succeeded
>    without permission problems.

I think I can see how this is failing now.  Consider this code:

    runAndReadStdout cmd = do
        ...
        s <- readFile output
        removeFile output   -- file will not be removed until readFile closes it
        return (safeinit s) -- strip trailing newline added by shell

The file-removal assumes the unix-like property that you can unlink a
file while it still has a (lazy) reader attached to it, and the file
contents will stick around until the reader has finished with it.
It is perfectly possible to create a new (different) file with the
same name as the old one whilst the old one is still being read.

Am I right in guessing that the Cygwin filesystem doesn't have these
semantics?

>    Is there an easy way for me to generate MkConfig.hc from 
>    MkConfig.hs, so that I can do some debugging?

Provided you have a working nhc98 installed, just use
    $ nhc98 -C MkConfig.hs
If there are no .hi files lying around, then it might need to be
    $ hmake -nhc98 -C MkConfig.hs

Regards,
    Malcolm