RTS option parsing

[Simon Marlow]

It's probably best not to rely on external libraries for this.

I'd be happy with representing the options as data rather than code, 
along with a generic parser.  Performance is very likely a non-issue, 
but you could always do something really simple like bucketing the 
options based on the first character.

Cheers,
	Simon

On 10/08/13 02:54, David Laing wrote:
> Hi Edward,
>
> I was more worried about the effect that it would have on the 2nd tier
> platforms, some of which don't have getopt_long_only - which I think is
> desirable due to the two-character short options that need to be dealt
> with.
>
> My feeling is that writing and maintaining a correct getopt_long_only as
> a fallback for those platforms - which I assume someone would have to do
> - might take more effort than putting togther something less general /
> more tailored to how the RTS parses the options.
>
> I've been idly thinking about how to approach this problem enough that I
> think I'm going to put some proof-of-concept code together just to test
> the ideas / so my metaphorical teeth stop itching.
>
> At the core of the idea is the options would be stored in an array of
> structs of the form
>    {option-string, has_argument, is_safe, function_pointer_to_handler}
> where the function pointer is probably of the form
>    int(RtsFlags*, some-error-info-struct*)
> or possibly
>    int(RtsFlags*, some-cross-option-information-sharing-struct*,
> some-error-info-struct*)
>
> I've been in the C++ world for a while now, so I'll need to double check
> the standard / idiomatic way to express that in C.
>
> If options don't effect anything but the flags or the error state, it
> seems to me that the overall complexity of the option parsing code would
> drop.  I don't know what the priority of option parsing performance is,
> but there are quite a few optimisations available that wouldn't
> complicate the code all that much.
>
> If anyone has any thoughts on this, I'd love to hear them before I get
> too far along.
>
> Cheers,
>
> Dave
>
>
> On Sat, Aug 10, 2013 at 10:09 AM, Edward Z. Yang <ezyang at mit.edu
> <mailto:ezyang at mit.edu>> wrote:
>
>     Hi David,
>
>      > I was initially thinking of something like getopt_long_only, as per:
>      > http://linux.die.net/man/3/getopt_long
>      > 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.
>
>     That's not necessarily true; we target MingW for Windows compilation,
>     so if you can make sure it works there getopt_long may be viable.  On
>     the other hand, maintaining backwards compatibility may be tricky.
>     Some investigation is probably necessary.
>
>     Edward
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>