
Is there a way to use Hat with GHC, without 'hmake'? The Hat Tutorial shows 'hmake' being used, but 'hmake' doesn't work for me. The problem is that 'hmake' seems to be looking for 'ghc' based on something other than PATH: $ ghc --make pointtracker.hs Chasing modules from: pointtracker.hs Compiling Util ( ./Util.hs, ./Util.o ) Compiling XSimpleIO ( ./XSimpleIO.hs, ./XSimpleIO.o ) Compiling Main ( pointtracker.hs, pointtracker.o ) Linking ... $ which ghc /home/frederik/.toast-i386/armed/bin/ghc $ hmake -hat pointtracker.hs Fail: Can't find module Graphics.X11.Xlib in user directories . Or in installed libraries/packages at /usr/lib/ghc-6.2.2/imports Asked for by: pointtracker.hs Fix using the -I, -P, or -package flags. Stop - hmake dependency error. i.e., I'm not sure how 'hmake' found /usr/lib/ghc-6.2.2, but this directory is not mentioned in my environment, and it was not my intention to use this version of ghc. Thanks, Frederik -- http://ofb.net/~frederik/

Frederik Eaton wrote:
Is there a way to use Hat with GHC, without 'hmake'?
Sure, you can make all calls to hat-trans and ghc directly yourself, but that is rather cumbersome. You cannot use anything like ghc --make, because ghc doesn't know about Hat.
The Hat Tutorial shows 'hmake' being used, but 'hmake' doesn't work for me. The problem is that 'hmake' seems to be looking for 'ghc' based on something other than PATH:
hmake uses its own little database of compilers. You can tell hmake about the compiler through hmake-config add ghc hmake-config default ghc http://www.haskell.org/hmake/hmake-config.html gives more details.
...
Fail: Can't find module Graphics.X11.Xlib in user directories
This indicates that you will run into a more serious problem. Hat currently only supports a limited set of libraries and Graphics.X11.Xlib is not among them. If an unsupported library is just a normal Haskell module, a simple solution is to copy it into the same directory as your own code (modify the module name accordingly) and just treat it as part of your program. However, this soon becomes more complicated if the library requires further modules and special link options. Ciao, Olaf

Frederik Eaton
Is there a way to use Hat with GHC, without 'hmake'?
You could transform each module in your project individually with hat-trans, before running ghc --make over the traced version. Unfortunately, this means you will need to find some other way to do the dependency analysis to ensure that modules are transformed in the right order. It is a known deficiency of the ghc --make implementation that it cannot handle pre-processors nicely - this applies equally to Happy, Alex, generic Haskell, etc. One way would be to write a Makefile, with rules something like $(patsubst %.hs, Hat/%.hs, ${SRCS}) : Hat/%.hs : %.hs hat-trans $< $(patsubst %.hs, Hat/%.o, ${SRCS}) : Hat/$.o : Hat/%.hs ghc -c -package hat $< and then use ghc -M to generate the dependencies somehow.
$ which ghc /home/frederik/.toast-i386/armed/bin/ghc $ hmake -hat pointtracker.hs
Fail: Can't find module Graphics.X11.Xlib in user directories . Or in installed libraries/packages at /usr/lib/ghc-6.2.2/imports Asked for by: pointtracker.hs Fix using the -I, -P, or -package flags.
Well, since ghc-6.2.2 doesn't ship with the X11 library package enabled, this is hardly surprising. However, even it it were supplied, you /might/ also need to ask for it explicitly with -package X11 on the command-line.
i.e., I'm not sure how 'hmake' found /usr/lib/ghc-6.2.2, but this directory is not mentioned in my environment, and it was not my intention to use this version of ghc.
You can select which version of ghc is used by hmake, either on the command-line, or by setting a default with hmake-config. e.g. hmake -hc=/home/frederik/.toast-i386/armed/bin/ghc ... or hmake-config list hmake-config add /home/frederik/.toast-i386/armed/bin/ghc hmake-config default /home/frederik/.toast-i386/armed/bin/ghc Regards, Malcolm

On Thu, Sep 01, 2005 at 04:46:38PM +0100, Malcolm Wallace wrote:
Frederik Eaton
writes: Is there a way to use Hat with GHC, without 'hmake'?
You could transform each module in your project individually with hat-trans, before running ghc --make over the traced version. Unfortunately, this means you will need to find some other way to do the dependency analysis to ensure that modules are transformed in the right order. It is a known deficiency of the ghc --make implementation that it cannot handle pre-processors nicely - this applies equally to Happy, Alex, generic Haskell, etc.
One way would be to write a Makefile, with rules something like
$(patsubst %.hs, Hat/%.hs, ${SRCS}) : Hat/%.hs : %.hs hat-trans $< $(patsubst %.hs, Hat/%.o, ${SRCS}) : Hat/$.o : Hat/%.hs ghc -c -package hat $<
and then use ghc -M to generate the dependencies somehow.
OK, I might try that.
...
i.e., I'm not sure how 'hmake' found /usr/lib/ghc-6.2.2, but this directory is not mentioned in my environment, and it was not my intention to use this version of ghc.
You can select which version of ghc is used by hmake, either on the command-line, or by setting a default with hmake-config. e.g. hmake -hc=/home/frederik/.toast-i386/armed/bin/ghc ... or hmake-config list hmake-config add /home/frederik/.toast-i386/armed/bin/ghc hmake-config default /home/frederik/.toast-i386/armed/bin/ghc
By the way, can I make a request to have the hmake default be to use the environment? I have to have my environment correctly configured anyway, to get other things to work, and hmake isn't saving me any trouble by asking me to duplicate this information in a different form. Now, it appears to be looking for 'ghc-pkg' in the library directory of 'ghc' (rather, again, than in $PATH) $ hmake-config add /home/frederik/.toast-i386/armed/bin/ghc $ hmake-config default /home/frederik/.toast-i386/armed/bin/ghc $ hmake -ghc -hat pointtracker.hs sh: /home/frederik/.toast-i386/armed/lib/ghc-6.4.1.20050812/bin/ghc-pkg: No such file or directory Fail: user error (Command (/home/frederik/.toast-i386/armed/lib/ghc-6.4.1.20050812/bin/ghc-pkg -l) failed) Stop - hmake dependency error. [1]$ which ghc-pkg /home/frederik/.toast-i386/armed/bin/ghc-pkg Frederik -- http://ofb.net/~frederik/

Frederik Eaton
By the way, can I make a request to have the hmake default be to use the environment?
Ian Lynagh recently added this capability to hmake, but it wasn't documented (until yesterday). The relevant option is hmake-config add-dyn ghc which causes the version of ghc to be probed every time hmake is run, rather than only once at configure-time. Thus, it should pick up the current environment settings as needed.
Now, it appears to be looking for 'ghc-pkg' in the library directory of 'ghc' (rather, again, than in $PATH)
Well, hmake absolutely needs to use the ghc-pkg that belongs to the particular version of ghc. The heuristic used to find it might be slightly fragile, but it is the best available, and indeed it is based on the information given by ghc itself. If the executable has been moved such that querying ghc for its location is no longer reliable, that's tough to fix. Regards, Malcolm

On Fri, Sep 02, 2005 at 10:22:06AM +0100, Malcolm Wallace wrote:
Frederik Eaton
writes: By the way, can I make a request to have the hmake default be to use the environment?
Ian Lynagh recently added this capability to hmake, but it wasn't documented (until yesterday). The relevant option is hmake-config add-dyn ghc which causes the version of ghc to be probed every time hmake is run, rather than only once at configure-time. Thus, it should pick up the current environment settings as needed.
OK.
Now, it appears to be looking for 'ghc-pkg' in the library directory of 'ghc' (rather, again, than in $PATH)
Well, hmake absolutely needs to use the ghc-pkg that belongs to the particular version of ghc. The heuristic used to find it might be slightly fragile, but it is the best available, and indeed it is based on the information given by ghc itself. If the executable has been moved such that querying ghc for its location is no longer reliable, that's tough to fix.
If 'ghc' could always tell you where the correct 'ghc-pkg' lives, then I guess that might be a reasonable way of doing things. However, nothing is strange about my installation, it is the default but with a different prefix, so something else must be broken. (And if 'hmake' had just gone with $PATH then it would have worked :) ) Frederik -- http://ofb.net/~frederik/
participants (3)
-
Frederik Eaton
-
Malcolm Wallace
-
Olaf Chitil