On Wed, 2007-06-13 at 15:24 -0700, Stefan O'Rear wrote:
> On Wed, Jun 13, 2007 at 11:33:36AM -0700, Bryan O'Sullivan wrote:
> Or better yet, put them directly in one of the LD_LIBRARY_PATH dirs.
> $PREFIX/lib/ghc-$VERSION is a relic of the static library system and
> IMO shouldn't be duplicated.
Hmm.. well what Felix does is:
(a) The bulk of the system lives in $PREFIX/lib/felix$VERSION
(b) Libraries are called *.flx or *.h or *.a or *.so and
have NO version encoding
(c) Executables are compiled and run using a bash script
The script is the only program installed in /usr/bin
This script selects the install to use, defaulting to the
most recent.
You can override the install directory on the script command line
or with an environment variable.
The bash script uses LD_LIBRARY_PATH, etc, and command line switches
to the executables, to ensure a coherent 'assembly' of components are
used together.
If you opt for static linkage, the resulting executable is of course
independent of the version.
All the standalone binaries require non-defaulted switches to
select where components other than load-time shared libs live.
This system supports multiple installations and also multiple
cross compilation.
IMHO: $PREFIX/lib/ghc-$VERSION style isn't a relic. It is the
current ridiculous versioning of shared libraries which is
a relic of even older faulty design which unfortunately
Debian and other package installers copied.
In particular, package components should always live in
the same directory tree, related by package/versions,
and NEVER get split up into lib/bin/include etc.
In fact that is a relic of archaic dog slow Unix directory searching,
and was a performance hack. It was never the correct design to split
packages into directories by function, and the Unix directory tree
is only capable of supporting C programs .. and it isn't really
suitable for C either.
The rules for package managers like Debian are that a component
library split into /usr/include, /usr/lib MUST have a man page,
and it MUST be a separately usable C/C++-callable component.
If the only user of these libraries is the Haskell or other
system, and the interfaces aren't documented, then the
libraries must NOT be placed in /usr/lib. In other words,
unless there is a distinct separable Debian package for the
library it must NOT go in /usr/lib.
The way most modern languages work, each version has a number
of utterly incompatible components. When you use Felix, Ocaml,
Mlton, or Haskell version xx.yy you can't use any other version
of any of the libraries .. and probably can't use any user libraries
either. It's likely the ABI (application binary interface) changes
with each version, the set of library entry points changes in
some detail, or whatever .. if not, why is a new version being
released??
This doesn't happen (usually) with C/C++, but it does sometimes:
the C++ ABI changed for Linux recently and it broke
Debian for months and months while everything got upgraded.
SO in my view, the only thing you might consider sharing
between (advanced language of your choice) versions is the source
code of software written in the standardised language -- but never,
NEVER the support libraries, run time, or compilers.
FYI: this is a particularly nasty problem for Ocaml, since the
ABI changes with every patch. The debian-ocaml team has to
rebuild and upload binaries to the package server every time
the compiler is changed .. and end users have to recompile
every program they wrote (for bytecode .. for native
code there's no dynamic loading anyhow), and every library
(for both bytecode and native code).
This isn't necessary with Felix because it *defines* execution
in terms of source code, not in terms of binaries, which are
regarded as mere cached values, and managed automatically
(i.e. rebuilt whenever there's a version mismatch).
So for something like Haskell I'd recommend the system be
split in two parts:
(a) the 'system' which provides a distinct installation
for every version all in a single directory tree
(b) libraries written in standardised Haskell 98 or whatever
are separate packages of source code, and are separately
maintained and installed
Any caching of partial compilations of the standard source
libraries should be automatic. Option (b) is rather hard
to organise without redesiging your tool chain to work
entirely in terms of source code .. but I recommend that
anyhow -- Haskell semantics are defined in terms of sources
and the 'average' user should know about anything else:
it's a basic principle of abstraction.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
