"Manuel M. T. Chakravarty" wrote:
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
nk 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
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
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
Don't know about binary dists, but I compiled 4.06 from source and
it did install directly in /usr/local/lib, which is IMHO not so good.
Many files used by a single package should generally go to a separate
subdirectory. I reran ./configure with some option to install in
I must admit I'm surprised by the reaction to my suggestion. Here /usr is shared
between lots of machines and there is no question of my installing GHC in /usr/bin
or anything like it. (The few system adminstrators here are all honest, overworked,
and sadly incorruptible.) My original problem
Just a few remarks and personal opinions from a RPM builder's view:
* IMHO the whole /usr/local hierarchy is completely obsolete for
and "real" programs should only be used for quick local hacks.
= GHC should reside under /usr/{bin,lib,include}
I'd rather say that the use of
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
Simon Marlow [EMAIL PROTECTED] wrote,
Don't know about binary dists, but I compiled 4.06 from source and
it did install directly in /usr/local/lib, which is IMHO not so good.
Many files used by a single package should generally go to a separate
subdirectory. I reran ./configure with some
On Tue, Feb 29, 2000 at 17:06:01 +, Marcin 'Qrczak' Kowalczyk wrote:
BTW, I see lack of standard way of conveniently installing a Haskell
library. For example c2hs installs in its own subdirectory and provides a
script c2hs-config which outputs compiler and linker flags necessary to
link
The latest binary distribution puts the GHC include files in
"lib/ghc-4.06/includes", not "lib/includes" as older versions used to.
This is a nuisance, because it means that there isn't any way a
Makefile can refer to the includes without coding in the GHC version.
Or is ther
The latest binary distribution puts the GHC include files in
"lib/ghc-4.06/includes", not "lib/includes" as older versions used to.
This is a nuisance, because it means that there isn't any way a
Makefile can refer to the includes without coding in the GHC version.
Or
Maybe there should be a standard place to put Haskell interfaces and
libraries/objects. As there can be many modules in a package and thus
many interfaces, and collisions between module names are harmless in
a case where both are not used in the same program, interfaces should
probably go to
13 matches
Mail list logo
