I notice that the method for detecting the configuration of ghc (for building 'hmake') no longer works with 5.02. This must be the most unstable part of ghc - I've had to change it at 4.06, 4.08, 5.00, and now 5.02 as well!
> ghc-pkg-5.00 --show-package std --field import_dirs /usr/malcolm/local/lib/ghc-5.00/imports/std > ghc-pkg-5.02 --show-package std --field import_dirs $libdir/imports/std
There does not appear to be any way to persuade the new ghc-pkg to reveal what $libdir is set to. Can someone give me a clue how to discover this information?
Oh woe is me. Sorry about that - we went to some effort to make the package configuration independent of the installation location, in order to make various things less fragile. The installation location can be discovered on a Unix system by looking up the -B<dir> argument in the ghc script. On a Windows installation, you have to derive $libdir from the location of GHC itself. Perhaps it would be easier to have hmake just invoke 'ghc --make' under the hood? Cheers, Simon
Simon Marlow wrote:
Perhaps it would be easier to have hmake just invoke 'ghc --make' under the hood?
I don't think ghc --make is mature enough to replace other make tools yet. For example, when trying to compile Fudgets with ghc-5.02 --make -O2, with GHCRTS=-M100M, I got GHC's heap exhausted; while trying to allocate 0 bytes in a 99999744-byte heap; use the `-H<size>' option to increase the total heap size. after about 2/3 of the library had compiled. GHC also left 54MB of junk behind in /tmp. I don't know exactly how big the heep needs to be, or how much free space in /tmp is needed to compile all of fudgets (285 modules), but I think it is clear that this behaviour is horrendous... As a comparison, using hmake, or some other make tool, fudgets compile just fine with ghc-5.02 -O2 , GHCRTS=-M40M (perhaps even less, I haven't tried), using only a few megabytes of space in /tmp. Additionally, ghc --make lacks (AFAIK) several useful features found in other make tools (although not all in the same tool...): 1. The ability to distingush directories containing source code to be compiled from directories containing previously compiled code (hmake has the flags -P and -i, hbcmake has -i and -I). (I guess you could use -package-conf as a cumbersome substitute, though.) 2. The ability to specify compiler flags for individual modules without putting them in the source code. (Some flags are 'static' and can not be put in the source code.) 3. The ability to compile several modules in parallel, on a multi-processor machine, or a network of workstations. 4. The ability to automatically invoke program generators (e.g. happy)... 5. A graphical user interface. Regards, Thomas Hallgren
participants (2)
-
Simon Marlow -
Thomas Hallgren