Spencer Janssen wrote:
On Sat, 16 Jun 2007 08:21:50 +1000
skaller <[EMAIL PROTECTED]> wrote:
One way to measure this is: if you removed GHC and applications,
and there are (necessarily) no users of the remaining library
package .. the library package shouldn't be in the global public
place (/usr/lib+include etc).
As I understand it, the entire point of this effort (shared libraries
in GHC) is to allow dynamically linked Haskell executables. In this
case, applications outside the GHC toolchain will in fact depend on
these shared objects. As a concrete case, a binary darcs package
could
be a user of libghc66-base.so and libghc66-mtl.so -- with no
dependencies on the GHC compiler package itself.
Does this pass your litmus test?
If a binary darcs package requires GHC libraries to function it would
be a GHC "application," so it would not pass the test. John
Skaller's point is actually very good, though it would require
special changes to the current system: distinguishing between GHC-
compiled _shared_libraries_ and the GHC compiler itself.
Under the current system ghc sits in its own subdirectory, typically /
usr/local/lib, /opt/local/lib, etc., depending on your distribution,
with only the compiler and "base" libraries. Relatively few Cabal
packages install into this directory--HaXml does, if i remember
correctly. Most Cabal packagers leave the default install, so
applications compiled by GHC are installed as subdirectories in the
user library directory (/usr/local/lib). So we have this layout:
/usr/local/lib/ghc-6.6.1 <--compiler, ghc-distribution libraries
/usr/local/lib/ghc-6.6.1/imports <-- .hi files
after installing HaXml:
/usr/local/lib/ghc-6.6.1 <- HaXml libraries
/usr/local/lib/ghc-6.6.1/imports <-- HaXml .hi files
after installing a default Cabal distribution (here, HXT):
/usr/local/lib/hxt-$(version) <-- libraries
/usr/local/lib/hxt-$(version)/imports <-- hxt .hi files
With the current setup is it is a real pain to go through and
uninstall all those extra libraries when you upgrade GHC: you must
either delete the directories completely (for directories based on
version, such as hxt-$(version), above); or, you must go into each
directory and delete the old libraries contained there. The ghc-pkg
program only handles finding these libraries for the ghc compile
process; it does not help with uninstalling them except by tracking
location.
I would extend John's idea--and reference to gcc's install layout:
everything should go into the generic "ghc" directory, say, /usr/
local/lib/ghc; _under_ that should go the compiler version (including
arch-platform); _under_ that may go user-libraries. That structure
would make it much easier for users to uninstall or upgrade ghc
versions. It also gives distributors the flexibility to include a
ghc-library-only distribution (no compiler) for packaging
applications--say, a basic darcs install (with shared libraries)
includes only the shared libraries it needs. A basic "ghc" directory
on top--no version until the next subdirectory--also preserves prime
real estate toward the top levels of the directory structure: a user
may install more than one version of GHC into their home directory
without flooding their home directory with ghc-$(version)s.
There is a fundamental flaw with all these "new" languages: ABI
changes between compiler versions force software vendors to give
customers upgrades of the entire program--you can't send a patch if
you need to compile all the libraries again. Static libraries are
horrible for the same problem, and one of the main reasons I will not
use OCaml for any distributable application. Even in-house, a hassle
like that means time and lost productivity. Patches are inevitable
for new features, security, etc., and changes to the compiler are
inevitable just to get around bugs in the compiler! GHC is a
research effort so it is a relatively fast moving target--how much
Haskell code has bit rotted simply due to changes in the GHC
compiler? In the past _three_ years? How much simply due to changes
in the _interface_ file (.hi) format? A lot. Too much to mention here.
Even if we can't standardise the ABI a bit the solution of where to
put libraries should place some real consideration on how much time
and trouble it is to uninstall and recompile everything, without
resorting to a script or package system to do it for us--you may
imagine the bug bath from, say, modifying ghc-pkg to handle
uninstallation.
Cheers,
Pete
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
