Re: GHC include files
Sven Panne <[EMAIL PROTECTED]> wrote, > 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? :-) Easy - I don't want to build an rpm which doesn't contain a version number in the path (for public use) only to compile ghc once more for myself with a version number in the path. So, better have everybody have the version number and share the binaries :-) Manuel
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
Re: GHC include files
Sven Panne wrote: > binaries go into /usr/bin, the whole rest into /usr/lib/ghc. So what's > the problem? :-) None. But can I suggest that if it's completely trivial we have ghc -display-include-path and ghc -display-libraries if that's easy to do? EG on this system ghc -display-libraries -syslib lang might output -L/usr/local/pub-bkb/ghc/ghc-binary/lib -lHSrts -lHS -lHS_cbits -lHSlang -lHSlang_cbits (Or something similar to be fed to ld.) This would (a) solve my currently problem (which is admittedly rather trivial); (b) not force me to go through ghc when linking Glasgow Haskell to something else.
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
FreeBSD port of 4.06
I've sent in a patch to upgrade the FreeBSD port of GHC to 4.06. If you don't want to wait until they get around to incorporating it, the patch is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=17115 Cheers, Simon
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 . . .
