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

Hackage trac at galois.com
Tue Aug 26 21:50:54 EDT 2008


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

 Well, first of all, I think it's a bad idea that Cabal has an option with
 exactly the same name as a GHC option that ostensibly does something
 similar, but with different semantics. That said, the best we can do is
 something to make it more obvious that the semantics are different, unless
 we sacrifice backward compatability.

 As to why people want to use this, I can think of a couple of good
 reasons. One is that some people like to build an entire source tree into
 an object tree directly with ghc, in which case you cannot have multiple
 modules named Main (at least not simply). The second is that it can save
 an extra file, or six or eight, if you've got that many command-line
 programs to generate.

 So is there a good reason to refuse to support this, for those ghc users
 that work this way? It seems to me it would be easy enough to extend the
 syntax of this option slightly to allow specifying the module and/or
 function to use as main. Perhaps something along the lines of "main-is:
 Foo.hs Foo.foo". In other words:

   main-is: Foo.hs         file Foo.hs, module Main, function main
   main-is: Foo.hs Bar     file Foo.hs, module Bar, function main
   main-is: Foo.hs baz     file Foo.hs, module Main, function baz
   main-is: Foo.hs Bar.baz file Foo.hs, module Bar, function baz

 This isn't quite compatable with ghc's main-is option, but it's close, at
 least, and maintains backward compatability with current main-is
 behaviour. Slightly more friendly might be to have the module name default
 to the module name declared inside the source file, if that's not too much
 work.

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


More information about the cabal-devel mailing list