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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
