Re: GHC include files

2000-03-02 Thread George Russell

"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

2000-03-02 Thread Sven Panne

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

2000-03-02 Thread Manuel M. T. Chakravarty

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