Re: GHC include files
"Manuel M. T. Chakravarty" wrote: Malcolm Wallace [EMAIL PROTECTED] wrote, Can I propose a change to the -i / -I flags? Currently, the -idir (or -Idir) options add a directory to the search path for imports. This directory is either relative to the current dir, or absolute. My suggestion is that it could also be used for "relative to a standard installation directory". For instance, -Idata/edison would look first in ./data/edison if it exists, then in $prefix/data/edison, where $prefix has the value /usr/local/lib/ghc, or whatever. I don't think this scheme would solve my problem at all. As has been pointed out before, I can already get the GHC include files appended by calling "ghc" and not "gcc". It's a good suggestion and one I shall probably follow. BUT it is not ideal because (a) ghc seems to munge up its arguments rather a lot - for example, it rearranges libraries which is a problem for Solaris when you are using the system linker; (b) if you had a huge C program to which you wanted to link a little Haskell, it would be silly to compile all the code in the C program with ghc, and it would also be silly to compile some C code with gcc and some with gcc. I'm not sure what would be best; perhaps what I want is ghc options which won't do any compiling, but just tell me where the include files and libraries are. So then I can type GHC_INCLUDES = `$(GHC) -display-includes` or something like that . . .
Re: GHC include files
It seems that the choice of the installation path depends more on religious thoughts than technical necessities. The only thing I was trying to say is that Joe User rarely needs 5 different versions of GHC at the same time, so I prefer paths without version numbers for my RPMs. Of course it makes sense for advanced GHC hackers to have different versions lying around, but those people normally build GHC from source anyway. And with the configure stuff relocating GHC is a piece of cake, e.g. with ./configure --prefix=/usr --libdir=/usr/lib/ghc binaries go into /usr/bin, the whole rest into /usr/lib/ghc. So what's the problem? :-) 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: GHC include files
George Russell [EMAIL PROTECTED] wrote, "Manuel M. T. Chakravarty" wrote: Malcolm Wallace [EMAIL PROTECTED] wrote, Can I propose a change to the -i / -I flags? Currently, the -idir (or -Idir) options add a directory to the search path for imports. This directory is either relative to the current dir, or absolute. My suggestion is that it could also be used for "relative to a standard installation directory". For instance, -Idata/edison would look first in ./data/edison if it exists, then in $prefix/data/edison, where $prefix has the value /usr/local/lib/ghc, or whatever. I don't think this scheme would solve my problem at all. As has been pointed out before, I can already get the GHC include files appended by calling "ghc" and not "gcc". It's a good suggestion and one I shall probably follow. BUT it is not ideal because (a) ghc seems to munge up its arguments rather a lot - for example, it rearranges libraries which is a problem for Solaris when you are using the system linker; (b) if you had a huge C program to which you wanted to link a little Haskell, it would be silly to compile all the code in the C program with ghc, and it would also be silly to compile some C code with gcc and some with gcc. I'm not sure what would be best; perhaps what I want is ghc options which won't do any compiling, but just tell me where the include files and libraries are. So then I can type GHC_INCLUDES = `$(GHC) -display-includes` or something like that . . . This is exactly what the `...-config' script that I was talking about is supposed to do. Now we can argue whether that should be part of `ghc' proper or an extra script. An extra script at least has the advantage that it is easier to maintain manual in case somebody moves a tree or so. Manuel