[Hackage] #148: Cabal should be able to produce foreign libs (shared or static)

[Hackage]

#148: Cabal should be able to produce foreign libs (shared or static)
----------------------------+-----------------------------------------------
  Reporter:  eivuokko       |        Owner:                 
      Type:  enhancement    |       Status:  new            
  Priority:  normal         |    Milestone:  Cabal-1.8      
 Component:  Cabal library  |      Version:  HEAD           
  Severity:  normal         |   Resolution:                 
  Keywords:                 |   Difficulty:  project(> week)
Ghcversion:                 |     Platform:                 
----------------------------+-----------------------------------------------
Changes (by duncan):

  * platform:  Windows =>
  * ghcversion:  6.4.2 =>
  * summary:  Cabal should be able to produce DLLs in Windows => Cabal
              should be able to produce foreign libs (shared
              or static)
  * milestone:  _|_ => Cabal-1.8

Comment:

 More people are trying to do this kind of thing, see:
 http://ha4.fajno.net/2009/03/pandoc-can-we-use-it-ouside-of-haskell.html

 There are also plenty of people in commercial settings doing this on
 Windows and who could do with more help from Cabal.

 This ticket mentions Windows and DLLs but we have the same issue with Unix
 systems and generating shared or static libs for consumption by foreign
 code. Whatever solution we come up with should be as cross-platform as
 possible.

 One question, is the choice of static lib or dynamic lib part of the
 package description or part of the way we choose to build it? Should we be
 able to build both from the same description? When you're building it,
 should you have to specify if you want to make a static lib or shared lib?

 For Haskell libs we have to say at configure time if we want shared or
 static. For this case perhaps it's more part of the package description
 than a configuration option.

 For Windows DLLs I hope there will be no need to specify `.def` files. We
 should be able to get the exact export list from the list of FFI
 ccall/stdcall exports.

 Note this issue is independent of whether ghc supports shared libs for the
 RTS and Haskell packages on a particular platform. If it doesn't we just
 generate massive libs that link in everything. If it does we can make
 small libs that dynamically link to the RTS and Haskell packages.

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