> 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
> /usr/local/lib/ghc-4.06 to have less mess directly in /usr/local/lib.
I think on reflection that /usr/local/lib/ghc or /usr/local/lib/ghc-4.06
would be a better choice than /usr/local/lib. In fact, binary distributions
already use the latter.
Include files, on the other hand, should really be in
/usr/local/include/ghc, so f.e. #include <ghc/RtsAPI.h> has a chance of
working.
> 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 an application with c2hs libs. OK, but should every package
> provide its own script?
I don't think so. Also, I don't think we should adopt a solution that
requires the programmer to know anything about how or where a particular
library is installed.
I had in mind a slight generalisation of GHC's syslib mechanism. Currently
GHC's libraries (HsLibs) are split into about 7 categories, and you can
bring a given category into scope by saying, eg. '-syslib text' on the
command line. GHC knows about dependencies between libraries, so you don't
need to say '-syslib lang' as well, if text depends on lang. The ordering
is also unimportant.
What we need is a way for external library writers to be able to package up
and distribute a library that will install onto a system with an existing
GHC such that you can say '-syslib <blah>' to get the new library. This is
pretty straightforward, we just need to separate out the syslib
configuration stuff from the driver, and write a (perl?) script to do the
installation. The script would be part of GHC, and invoked as part of the
library installation.
In the long term, I hope Haskell will get a hiearchical module namespace and
we can do away with the -syslib option altogether. We're also working
towards expanding the library collection to be a lot more comprehensive;
we've now incorporated HaXml, for instance.
> Simon Marlow has already explained why shared libraries are currently
> impossible... A pity. Hope that at some time someone will anyway
> do them, possibly not using standard Unix linker if problems are
> specifically with it itself rather than with the concept.
Good news on this front: due to a truly heroic effort on the part of Julian,
STG-Hugs is just about able to load GHC-compiled modules, which means you
can compile Main.hs into Main.o, and run it inside STG-Hugs against the
compiled prelude/libraries etc. Strictly speaking it's dynamic linking, not
shared libraries, but you still get the disk-space and link-time savings.
If the linker were separated out from Hugs and included in GHC's RTS, we'd
have a way to generate standalone dynamically-linked binaries.
Cheers,
Simon
