RE: ghc --make -odir x -hidir x chooses strange location for x
I'd have expected -odir/-hidir to put files in directories relative to the source directories. Is that an unreasonable expectation?
No, it's not an unreasonable expectation, and in fact I've made that change in CVS. However the changes are too large to backport to 5.04.2, I'm afraid.
2) with static options not accepted in source file pragmas, I often end up compiling everything with the superset of options.
Shouldn't it be possible to fork a new copy of ghc with new static options for parts of a ghc --make run?
Which static options in particular do you need to change?
3) shouldn't there be a way of telling ghc --make about ways to generate the .hs/.lhs files it is looking for (aka suffix rules)?
The standard examples are happy, cpp, drift, ..
As Malcolm suggested, use hmake, or a Makefile (and suffer slower compile times, I'm afraid). I don't think we intend to implement this in GHC. Cheers, Simon
I'd have expected -odir/-hidir to put files in directories relative to the source directories. Is that an unreasonable expectation? in fact I've made that change in CVS. However the changes are too large to backport to 5.04.2, I'm afraid.
Great! What is the release schedule for 5.06?-)
2) with static options not accepted in source file pragmas, I often end up compiling everything with the superset of options. Shouldn't it be possible to fork a new copy of ghc with new static options for parts of a ghc --make run?
Which static options in particular do you need to change?
Just the usual suspects: -package mostly for me, the occasional -O for sources from folks who have figured out which of their many files really need/profit from optimisation. Was interesting to look at the list again, though - in my memory, the list of static flags was longer than it actually turns out to be. -package seems to be the only one left that really hurts.. Well, and the lower level equivalents, of course: -i, -l, -L (these would be especially useful in combination with ghci: just have everything in one file, pass it to ghci and get going..). Thanks, Claus
Good morning, I wrote a very small program, and it executed ok. I wanted to export a function in "C", and therefore wrote a "C" wrapper function over it to invoke peekCString and peekArray on the input; newCString and newArray on the output. I then did a small "C" driver program. Everything compiled and linked correctly. But at execution the program prints : EVACUATED object entered! as soon as "startupHaskell" is invoked (i.e. even before I call my foreign exported function !) What is the meaning of this message ? Thank you Francis Girard Le Conquet France
participants (3)
-
Claus Reinke -
Francis Girard -
Simon Marlow