new Library Infrastructure spec.

[Alastair Reid]

> 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 
this are:

- Persuade the cabal authors to add enough config/make functionality
  to Cabal that I can rewrite the configure/make scripts in some 
  Cabalish syntax.

  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
   original library.

- Invoke the existing config/make infrastructure when installing the
  Haskell binding.

  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.

--
Alastair Reid