Re: RTS option parsing

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 mailto:ezyang@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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs