RTS option parsing

David Laing dave.laing.80 at gmail.com
Fri Aug 9 13:29:50 CEST 2013


I'm brand new to GHC development, and have been looking at:

I was initially thinking of something like getopt_long_only, as per:
however it looks like the portability of that function isn't the greatest,
and from looking at rts/RtsFlags.c:procRtsOpts(...) it might not be the
best solution.

Unless I've missed something, it seems that the processing of each flag is
independent of the others, at least once we get into procRtsOpts(...), and
the processing of a flag either mutates the RtsFlags variable or results in
an error.

If that's not likely / wanted to change I think there are some nifty ways
to abstract that, as long as function pointers aren't frowned on in the RTS
code :)

Since it looks like it would be a sizeable patch, should I put together a
proof-of-concept and ask for feedback sooner rather than later?  I'd hate
to emerge from my codecave with a fully-formed but unacceptable solution.

While I'm at it - does anyone have any thoughts or wishlists for a cleaned
up option parser?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130809/02fc8dda/attachment.htm>

More information about the ghc-devs mailing list