[Hackage] #179: support GHC's main-is extension

Hackage cvs-ghc at haskell.org
Sat Jun 18 20:07:28 CEST 2011

#179: support GHC's main-is extension
  Reporter:  duncan         |        Owner:          
      Type:  enhancement    |       Status:  reopened
  Priority:  low            |    Milestone:  _|_     
 Component:  Cabal library  |      Version: 
  Severity:  normal         |   Resolution:          
  Keywords:                 |   Difficulty:  normal  
Ghcversion:  6.4.2          |     Platform:  Linux   
Changes (by duncan):

  * status:  closed => reopened
  * resolution:  wontfix =>


 It's quite true that we do support non-portable packages that work with
 one Haskell implementation and not another, but that's usually for
 substantive useful features. To me, the `main-is` thing seems to add so
 little value that the benefits of adding it are outweighed by the fact
 that it introduces extra non-portability.

 Clearly some people disagree with me and think it'd be jolly useful. Given
 that, I'd be happy to accept a patch that works by generating stub main.hs
 modules that import the user's chosen main (optionally and as a slight
 optimisation the implementation could use ghc's flag when compiling with
 ghc). The point is, it'd be portable.

 There's still the issue of how to specify the main entry point. Any
 suggestions? I had one suggestion in the first comment above. It'd be:

 main-is: Blah.hs
 main-module-is: Blah.main

 That's no so nice though. You want to be able to specify the module and
 function sometimes, and other times just the module and let the function
 default to 'main'. Perhaps a different named field, like:
 main-is: Blah.hs
 main-entrypoint: Blah.main

 Note that related to this is that people want main in .c files, and
 sometimes they want main to come from a library (silly sdl libs).

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

More information about the cabal-devel mailing list