RE: Preprocessor question
> Please, can somebody explain, why the preprocessor is > hardcoded in the GHC > perl scripts? IIRC ghc (the perlscript itself) doesn't even reference > $RAWCPP. mkdependHS and hscpp do, but why an absolute path > and this obscure > "-iprefix" parameter? Again, "-iwithprefix" is never used... > > Would it break things, if there is '$RAWCPP = "cpp > -traditional"' only? It isn't strictly speaking hardcoded, it's set up when you configure a binary distribution. So if you move gcc or install a new version, you need to re-install ghc. The reasons are pretty boring - - mkdependHS and friends need a cpp that accepts input on stdin, and files that don't end in ".c". That rules out 'gcc -E'. - many systems don't have a /lib/cpp (or any other easy way to get at cpp), or if they do it is just a synonym for 'gcc -E', which is no good. On some systems it lives somewhere else (eg. /usr/libexec/cpp on BSD4.4-derived systems). I suppose we can put in a configure test for known locations of cpp (/lib/cpp, /usr/libexec/cpp, /usr/lib/cpp) and use that in preference to anything else if it works. If anyone sends me a *complete* patch which does the right thing, then I'll incorporate it. Cheers, Simon
Preprocessor question
Hi! Please, can somebody explain, why the preprocessor is hardcoded in the GHC perl scripts? IIRC ghc (the perlscript itself) doesn't even reference $RAWCPP. mkdependHS and hscpp do, but why an absolute path and this obscure "-iprefix" parameter? Again, "-iwithprefix" is never used... Would it break things, if there is '$RAWCPP = "cpp -traditional"' only? Cheers, Michael -- W*ndoze NT is faster... CRASHING!
Re: Problem with 4.03 FFI on Sparc?
[ redirected to ghu ] "Frank A. Christoph" wrote: > I wrote: > > * A more pressing point is that GHC is tied to x86 machines at > >moment, see e.g. MBlock.c or Adjustor.c. > It is? I thought these were only relevant for the FFI. OK, I was a little vague: MBlock.c is needed by the RTS in any case and *guesses* a free region in virtual memory for most architectures. Most guesses seem to be quite good, though. Adjustor.c is only necessary for foreign export dynamic, so most programs (if not written by Manuel or me :-) won't notice the omission, but it is exactly this kind of tiny differences between platforms SuSE tries to avoid. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: Problem with 4.03 FFI on Sparc?
Just an aside: Due to some pushing on my part Hugs98 made it onto the SuSE distribution (6.2), but none of the Glasgow fptools. There are two reasons for this: * SuSE's internal way of building packages makes a self-compiling program like GHC a little bit hard to integrate. But this is a solvable problem, either via some hand-made GHC or *.hc files. * A more pressing point is that GHC is tied to x86 machines at moment, see e.g. MBlock.c or Adjustor.c. SuSE has a Linux version for Alpha, too, and includes packages only if they work on *both* platforms. So my question is: Is there an Alpha aficionado out there to fill these holes in GHC? It would be nice if GHC were included in a mainstream Linux distribution. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: calling void foo(void) C functions from haskell
Peter Amstutz <[EMAIL PROTECTED]> wrote, > I'm experimenting with the haskell FFI, and have run into a odd little > problem. For some reason, ghc won't let me import functions with no > arguments... > [...] > And my first try (for.hs) > > foreign import ccall "hiworld.so" "hiworld" hiworld :: () -> IO () > > main = hiworld () > > and I get: > $ ghc for.hs hw.so -fglasgow-exts > for.hs:5: > Unacceptable argument type in foreign declaration: () > When checking declaration: > foreign import _ccall "hiworld.so" "hiworld" hiworld :: () -> IO > () Try foreign import ccall "hiworld.so" "hiworld" hiworld :: IO () In other words, a function of no arguments is a constant. Remember that evaluating a monad expression of `IO ()' does not yet execute the I/O operation - it merely produces an ``action'' that, once executed, performs the I/O operation. This is a fine, but very important difference. Manuel
