#179: support GHC's main-is extension
----------------------------+-----------------------------------------------
Reporter: duncan | Owner:
Type: enhancement | Status: reopened
Priority: low | Milestone: _|_
Component: Cabal library | Version: 1.2.2.0
Severity: normal | Resolution:
Keywords: | Difficulty: normal
Ghcversion: 6.4.2 | Platform: Linux
----------------------------+-----------------------------------------------
Changes (by duncan):
* status: closed => reopened
* resolution: wontfix =>
Comment:
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
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
