Edward Z. Yang
ezyang at MIT.EDU
Wed Aug 3 03:09:34 CEST 2011
Excerpts from Victor Nazarov's message of Tue Aug 02 19:12:55 -0400 2011:
> I can parse arguments myself
> and throw the rest of them to parseDynamicFlags, but GHC's flags are
> really complicated and I'm not aware
> of any argument parsing library that can be used to filter out some
> specified flags and return the rest GHC's flags untouched.
Your best bet is to use '--' or something similar to demarcate GHCJS
flags, and GHC flags, and then manually split them up before passing
them off to your preferred command line parser.
Though this vaguely sounds like something that might be nice to support
in GHC proper, though I would not be the best person to ask about this.
> For now I'm using (abusing) ccall calling convention and simple
> imports works pretty well, but I would like to support
> exports and static/dynamic wrappers. GHC generates C-code to support
> stubs. Is it possible at all?
That is certainly not; you'll need to patch GHC's lexer to do that.
But it's all a bit dodgy since this FFI doesn't make sense unless you are
comment on that. (Perhaps we need fully extensible calling convention
> I'd like to create ghcjs and ghcjs-pkg tools that will use their own
> directories and package index and will
> not interfere with ghc. Is it possible with GHC API? How can I do it?
Check out the approach that cabal-dev uses, which is about what you
are looking for here. (Though, handling base packages might be tricky.)
More information about the Glasgow-haskell-users