[Hackage] #704: sort out design for foreign code in Haskell libraries

[Hackage]

#704: sort out design for foreign code in Haskell libraries
----------------------------+-----------------------------------------------
  Reporter:  duncan         |        Owner:         
      Type:  task           |       Status:  new    
  Priority:  normal         |    Milestone:         
 Component:  Cabal library  |      Version:  1.6.0.3
  Severity:  normal         |     Keywords:         
Difficulty:  unknown        |   Ghcversion:         
  Platform:                 |  
----------------------------+-----------------------------------------------
 Currently we often happily add little bits of C glue code into Haskell
 packages. This is perfectly reasonably but we also want to be able to do
 things like linking multiple versions of a Haskell package into a single
 application. That does not work if the C symbols are visible outside of
 the package (see #701).

 It seems reasonable to require that C code in a Haskell package respects
 the properties that we want for Haskell packages. However we must also
 allow for libraries that are foreign code and not Haskell libraries at
 all.

 For example, the zlib binding package ships a complete copy of the zlib C
 code for platforms that do not have it natively. Unlike bits of FFI glue
 code, it is unreasonable to expect to change the zlib code to conform to
 Haskell library requirements.

 Perhaps what we need is to explicitly identify foreign libraries and hold
 them to different (lower) standards compared to Haskell libraries. One
 idea would be to draw together the features proposed in these tickets:

   * #276 : support for convenience libraries
   * #148 : producing foreign libraires

 The idea with convenience libraries is that a package can have multiple
 libraries in it, even though at most one can be the library that has
 exposed modules. Other libraries could be used by executables or the main
 library in that package. The main purpose is sharing but it could also be
 a way to separate the requirements of haskell code and foreign code.

 Producing foreign libraries is about making libraries (usually but not
 necessarily containing Haskell code) that export a foreign C API and are
 not intended to be used by other Haskell code.

 Combining these two features would allow for the zlib example to work ok.
 We would declare a foreign library with the zlib C code and make the main
 Haskell binding library depend on it. Note that packages that depend on
 the binding package would not directly link to the C library (this is
 significant for shared libs).

 The key constraint for foreign libraries is that we cannot link more than
 one version into a single application (because the symbols would clash),
 where as we may assume that it is perfectly safe to link multiple versions
 of a Haskell package.

 Any design must also consider symbol visibility. This is relevant both for
 shared and static libs. With static libs it is hard to avoid every symbol
 being globally visible. With shared libs there is greater control over
 symbol visibility but also the restriction on some systems that each
 shared lib must resolve all symbol references. This means we must more
 explicitly identify which libraries import symbols from others.

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/704>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects