new Library Infrastructure spec.
alastair at reid-consulting-uk.ltd.uk
Tue Jun 8 04:53:38 EDT 2004
> If we can step back for a moment, I think you're saying that
> supporting Marcus isn't that important, or that it's too hard. Maybe
> we could break up the argument along the lines of:
> 1) Why we should / shouldn't support Marcus
Perhaps a semi-concrete example of a Marcus would help here.
Suppose I find a really cool library written in C.
It's fast, well documented, somewhat portable and too big to rewrite in
Haskell so I write:
- a Haskell binding for it
- some little auxillary C functions (you often need these when you
write bindings for big libraries).
If it was available as a Debian (say) package, I might be able to survive in
"Angela mode". That is, I'd use the simple installation scripts demonstrated
in the Cabal documents.
[There are some issues here like arranging for compilation of the auxillary C
functions and passing appropriate linker flags to the compiler which may mean
that I can't quite use the simple scripts.]
But, if the C library comes with a complex configure/makefile system and isn't
available as a Debian/FreeBSD/Microsoft/etc package and maybe needs modified
a bit for use from Haskell, then installing the Haskell binding requires me
to configure, compile and link the C library first. My options for doing
- Persuade the cabal authors to add enough config/make functionality
to Cabal that I can rewrite the configure/make scripts in some
Obviously, this is insane.
Too hard to add all that stuff to Cabal and
now we have to keep our copy in sync with future releases of the
- Invoke the existing config/make infrastructure when installing the
I hope it's obvious that this is the better option.
There's probably other examples involving use of complex Haskell
preprocessors, machine generated Haskell code, C-to-Haskell translators, etc.
which are beyond the simple installation system.
More information about the Libraries