On Jun 19, 2007, at 4:05 AM, Simon Marlow wrote:
Peter Tanski wrote:
Now each GHC-Haskell-based program installer would search /usr/
local/lib for, say, libHSrts_dyn-6.6.1.dylib and install that
version if necessary. What happens on uninstall?...
That is why I think your idea was good: put everything into
distinct directories.
We are not intending to build-in any particular knowledge about
where shared libraries are to be installed - that's up to the
packager.
Definitely. It would be non-portable if GHC baked the install
directory into the shared library install_name (using libtool lingo)
whenever a programmer (or Cabal) invoked ghc --make.
With one exception - we have to pick a default for the .tar.bz2
binary distributions (and 'make install'), and the only default
that makes sense is to install the shared libraries in the standard
location, /usr/local/lib. Otherwise the system will not find them,
and GHC itself will not run (assuming it is dynamically linked).
You don't get good uninstall support, but that's always been the
way if you don't use the system package manager.
I advocated putting everything in /usr/local/lib/ghc/ghc-$(version)
earlier. The dynamic-library system used for ghc-6.4 on OS X worked
fine; do you remember any problems when that was put together?
Stefan O'Rear seemed against flooding /usr/local/lib with ghc-
libraries--I'll admit my own /usr/local/lib is a bit messy even
considering I use 'port' for quite a few programs--but also argued
that the dynamic libraries should not go in the /usr/local/lib/ghc-$
(version). The de-facto standard for systems that have C or C++-
compliant dynamic libraries seems to be:
shared libraries go in:
/usr/local/lib
static libraries or system-specific libraries go in:
/usr/local/lib/$(system)/$(system_version) or $(build)/$(system_version)
So for nhc98, the static libraries are in /usr/local/lib/nhc98/$
(build); for yhc, the .ycr files are in /usr/local/lib/yhc/packages/
yhc-base/$(yhc_version); for felix the .flx files (as source code)
are in /usr/local/lib/felix/$(felix_version)/lib; for ocaml, the .cmx
and .cmi files go in /usr/local/lib/ocaml; but for chicken-scheme the
dynamic libraries (only really usable through the chicken interface
but definitely "pure" C in the end) are in /usr/local/lib. I should
not neglect to say the same goes for python, although . The one
exception seems to be for gcc's libstdc++, which has a symlink in the
same directory as the static libraries. Following what I--perhaps
mistakenly--called the 'de facto' standard, if ghc dynamic libraries
are callable from C (they are), then the dynamic libraries should go
into /usr/local/lib. I would highly suggest that symlinking an un-
versioned name to each version would create a mess, so the library
names should only follow the real version. Stefan does have a point,
so the default installer might place dynamic libraries in a user
library directory such as $(home)/lib--a real consideration for
students and others who work on a large shared system where the
sysadmin does not want to support yet another language installation.
What seems backwards (to me) are the Haskell programs: it would be
fine if the standard install for program static libraries and
interfaces went into the ghc-$(version) directory but they don't and
when we had dynamic libraries on OS X they followed the static
library convention: each program is installed into /usr/local/lib/$
(program) or $(program)-$(version). Some programs place libraries
directly into the program directory while others place the libraries
under a $(haskell_compiler)-$(haskell_compiler_version) directory.
This duplicates the ghc system of /usr/local/lib/ghc-$(version) for
each Haskell program and creates a real mess--more so than other
languages. I agree, this is not really GHC's problem but the ghc
location might help, which is why I suggested /usr/local/lib/ghc/ghc-$
(version). It might even be extendable to all of Haskell: ghc should
go into /usr/local/lib/haskell/ghc-$(version), so, say, yhc could go
into /usr/local/lib/haskell/yhc and the installed programs would go
into /usr/local/lib/haskell/$(compiler). Much cleaner and much
easier for a package system to manage.
I have written too much on this, so I'll shut up--whatever you decide
is fine; I'll fix the install script to create a PackageMaker .pkg
following whatever you decide and post it if you want it.
Cheers,
Pete
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
