Thinking about it further, I like the convention that the target of runhaskell
MUST be Main.main. It simplifies a lot of assumptions about intent. It means
that if I put a module named Main in HAppS/HTTP/FileServer, searchpath doesn't
have to do anything special to figure out what it should do.
sp runhaskell --sp HAppS.HTTP.FileServer --http-port=7000
Will download everything required at start serving files out of the current
directory on port 7000 no fuss and no muss. I withdraw the complaint and the
bug report.
Note: In the next version of searchpath I hope to get rid of the --sp and have
it just know that if it doesn't see the module on the path, it should download
it.
-Alex-
On Mon, 30 Apr 2007, Simon Marlow wrote:
S. Alexander Jacobson wrote:
I've since modified sp to add a main-is which prevents the panic and
replaces it with a complaint about Main e.g.
runghc -i.haskell_cache/http_searchpath.org-default.map.cache -main-is
HAppS.Protocols.HTTP.FileServer.main
.haskell_cache/http_searchpath.org-default.map.cache/HAppS/Protocols/HTTP/FileServer.hs
--http-port=7000
<interactive>:1:211:
Failed to load interface for `Main':
Use -v to see a list of the files searched for.
runghc expects to run Main.main, I'm afraid it doesn't pay any attention to
the -main-is flag (this flag is just passed along to GHC). We do have a
:main command that runghc really ought to use, but unfortunately it's not
quite that simple. I'll create a ticket, thanks for the bug report.
Instead of runghc, as a workaround you could use ghc -e directly.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
