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