RE: [nhc-bugs] Building nhc98 on Windows 2000
I've had half an eye on this discussion... just a couple of things to add:
grep: /cygdrive/c/ghc/ghc-5.02.2/bin/ghc: No such file or directory
Ah, yes I think I remember reading once that GHC/mingw32 does not have a driver script, only a directly executable binary. Hence, grepping through the script for configuration information (as hmake-config is attempting to do here) is no longer an option. Unfortunately, I'm not aware of any other way to reliably get config info out of GHC.
'ghc -v' on 5.00 and 5.02 (and later versions) will tell you where the package config file is, and the rest of the info can be extracted from that. However, you do know that we're planning to move to binary interface files, right? Perhaps we should rethink how hmake gets hold of its info about libraries - what exactly does it need to know?
Sadly, the difficulty of using GHC/mingw32 as a bootstrapping compiler seems to be increasing the more we delve into it. Perhaps it would be safest for us simply to recommend GHC/cygwin instead, and disallow the GHC/mingw32 route.
I don't know whether Sigbjorn plans to continue supporting this route - Sigbjorn? Cheers, Simon
Hi Simon,
'ghc -v' on 5.00 and 5.02 (and later versions) will tell you where the package config file is, and the rest of the info can be extracted from that.
Useful to know. However, the value of $libdir is not defined in the package config file, and that is the information I was grepping for in the driver script... Actually, `ghc -v' (with 5.02.2) seems to dump the entire package config to stdout with $libdir expanded out. This might be sufficient for me, but I need to know whether that behaviour is consistent across all versions of ghc >= 5.00?
However, you do know that we're planning to move to binary interface files, right? Perhaps we should rethink how hmake gets hold of its info about libraries - what exactly does it need to know?
The format of the interface files is irrelevant to hmake - it doesn't read them, it only checks for their existence. The basic requirement for hmake is that every module mentioned in an import must have a referent. The referent can be a source module (.hs, .lhs, .ly, .gc, etc), or if the sources are not available (e.g. Prelude, or a package module) then an interface (.hi file) will do. Source modules are scanned for further dependencies, but interface-only modules are assumed to be leaves of the graph. Regards, Malcolm
"Simon Marlow"
...
Sadly, the difficulty of using GHC/mingw32 as a bootstrapping compiler seems to be increasing the more we delve into it. Perhaps it would be safest for us simply to recommend GHC/cygwin instead, and disallow the GHC/mingw32 route.
I don't know whether Sigbjorn plans to continue supporting this route - Sigbjorn?
Is there really a demand for it? Judging by the download logs for the cygwin snapshot I put out last week, I remain unconvinced that it's worth the effort (i.e., 'wasting' a day+ to fix up & package a release that's been downloaded by _one_ single soul, doesn't strike me as a worthwhile way to be spending my free time.) Is there a description of what's wrong with the released Windows version of GHC wrt. compiling up nhc98? --sigbjorn
participants (3)
-
Malcolm Wallace -
Sigbjorn Finne -
Simon Marlow