Pragmas for FFI imports

[Simon Marlow]

On 21 February 2006 18:14, Einar Karttunen wrote:

> On 21.02 16:50, Simon Marlow wrote:
>> I lost the argument for include files, but this is why libraries
>> cannot currently be specified inside source files.  Back in the FFI
>> discussion, we didn't have Cabal, but now that we do, Cabal is the
>> natural place to specify these things.
> 
> Cabal is a good place, but does not handle very well optional
> dependencies that most programs linking against the library
> don't need.
> 
>> I don't understand this - surely if you just put those two modules in
>> separate packages, then everything works?  Or is it that you don't
>> want to do that?
> 
> Think about a database library supporting e.g. mysql, postgresql,
> sqlite and odbc. Now it needs six packages to do this:
> 1) foo-common for common code that does not import any of the
> implementations 2) foo-mysql (depends on 1)
> 3) foo-pgsql (depends on 1)
> 4) foo-sqlit (depends on 1)
> 5) foo-odbc  (depends on 1)
> 6) foo (this has a connect function which uses any of the above, thus
>    depends on 1, 2, 3, 4, 5)
> 
> I don't consider this very good design and in practise this is quite
> tedious for the library writer.

This is exactly what you need to do.  The rationale is this:  for
simplicity, packages are the unit in several concepts: distribution,
dependency, versioning, licensing, dynamic linking, include file
dependencies, external library dependencies, and more.  If we start
confusing the issue by having smaller units for some of these concepts,
things get even more complicated.  

I don't think that requiring a package distinction in order to have a
distinction between external library dependencies is too onerous.
Packages are supposed to be lightweight things - if it is too difficult
to divide a package, then we should address that in the tools and
infrastructure.  (I think it is more difficult than it needs to be right
now, but we have been thinking about how groups of packages should look
to the Cabal user recently - see discussions on the libraries list).

Cheers,
	Simon