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 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.
I like the use of a prefix including the program name and
version number very much, as I usually have about three
versions of ghc installed (the latest stable release, the
stable release before that, and the current cvs version).
I understand Sven's position on that matter, but only
because some packages make a mess out of the installation
doesn't mean that we can't find a nice way to let different
versions co-exist.
> 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.
That is indeed a problem.
> > 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.
I will still have to use `c2hs-config'[1]. The point of
`c2hs-config' is to provide a truely OS and compiler
system-independent way of using C->HS. So, unless the
Haskell language definition enforces a fixed policy on
library organisation, the need for `c2hs-config' won't go
away.
In fact, the concept behind `c2hs-config' is not my own
idea. It is the mechanism used by the GTK+ and Gnome
libraries - ie, even C libraries run into essentially the
same problems as we do.
There are quite a number of subtleties involved here:
* How do I get the version of a library? (I just use
`c2hs-config --version'.)
* How can I have two versions of the same library installed?
(With `c2hs-config' they can be installed with different
prefixes.)
* How can I select between different versions of one
library? Eg, how can I have
./configure --cool-lib=<whichever>
style options in a program using the library.
(With `c2hs-config', you just provide the path to the
c2hs-config script you want - the script knows the rest.)
* How can I handle multi-language programs/libraries (eg,
mixed C and Haskell code)? (The `...-config' script gets
different flags for the different languages involved.)
* How can I select between different capabilities of my
library (with or without threads or so)? (`gtk-config' is
called with or without the `gthread' argument).
I don't know of any other configuration mechanism that
handles all these things gracefully.
Cheers,
Manuel
[1] For those who don't know how `c2hs-config' works:
http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs-2.html#ss2.1
