RTS option parsing

[David Laing]

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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130810/5765fc2b/attachment.htm>