The original code in the makefile.lib replaced
(basename input.hs) with (basename output.o)
and
*.hi with *.o
which is a quite weird approach to the problem. I'am not sure but I
think the new approach is better:
let the .o files be correct through the -odir flag
replace (dir input
Georg Martius wrote:
Hi,
Patrick and I found some answers to the questions/problems we encountered.
Finally got the thing to work. (patches appended)
Great!
I have a possible fix:
add -odir out/... to the call of ghc -M. This produces correct paths
for the .o files.
Ok, this makes sense and, i
Ivan Boldyrev wrote:
On 8861 day of my life Mike Thomas wrote:
| Is that a good option? How can I use the wxHaskell libraries with GHC?
| I´m working under Windows XP.
Check out wxHaskell:
http://wxhaskell.sourceforge.net/
Does it work under Windows?
One of my friends tried it under Windows, but fa
On Wed, 14 Apr 2004 09:37:02 +0100, Simon Marlow <[EMAIL PROTECTED]> wrote:
> What error messages do you get, specifically?
Here it is:
---
Loading package data ... linking ... done.
Loading package wxcore ... ghc-6.2.1: can't load .so/.DLL
for: wxc-gtk2.4.2-0.7
(/usr/
> These things are always tricky to understand, which is why I recommend
> not using lazy I/O. File reading is not a pure operation: running out
> of file descriptors is a good counter-example.
Without saying wether I agree with lazy I/O or not, I suggest that
this particular problem may also be
> > Great! I haven't seen it before.
Thanks,
I haven't announced Parsec yet since it is still under development. (due to
TokenDef for example :-)
> > Oops, what about the TokenDef module? Even if it can be done using
> > some hi-boot stuff, looks as a strange design, and only one instance
> > can
