Tue, 29 Feb 2000 10:24:34 +0100, George Russell <[EMAIL PROTECTED]> pisze:
> The latest binary distribution puts the GHC include files in
> "lib/ghc-4.06/includes", not "lib/includes" as older versions used to.
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.
> 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.
You can call ghc to compile C files. They will get the necessary
options.
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?
Putting C headers in a standard place like /usr/include or
/usr/local/include and C libraries in /usr/lib is convenient.
Looks like a contradiction for my statement in the first paragraph,
but here many programs use them; it's inconvenient to design each
time another script which tells Makefiles what options to use.
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 a separate directories for each package.
IMHO there should be a flag similar to -syslib which tells the compiler
and linker to use a package of a given name from such standard
directory (hoping that there will be no name clashes): search for
interfaces there and link a library. Not depending on whether it is
under /usr/lib or /usr/local/lib - packages themselves should not be
required to separately announce where they reside.
It's possible that a package requires some additional compiler flags
when it is used. For example linking packages or syslibs or C libs
it depends on. So maybe the package's subdirectory under standard
Haskell directory could contain a file describing additional compiler
and linker options needed. Particularly the -l option which links
the relevant library would be simply there.
Will ghc change interface format with each version? :-) This is what
makes reuse harder - not to say that there are other incompatibilities:
fromInt/toInt, syslib reorganization, Haskell language versions,
evolving FFI - ugh, there is only a little chance that a random package
like gtk+hs or TclHaskell will still compile without tweaking under
a new ghc version.
For C there are plenty of libraries, and in simple cases I only add
#include, linker's -l option and just use it. Haskell has much better
module system, but in ghc making packages is still inconvenient. I
hope that at some time there will be many Haskell libraries to choose
from too, but they need some infrastructure to maintain packages
conveniently.
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.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
