Add more robust option parsing [WIP]

[evanlucas]

This is a start for adding more robust option parsing. I wanted to go ahead and open this to get some feedback on the direction.

Note: this is by no means complete and there are failing tests from it currently

I have included the option parser found at https://github.com/JGiard/tclap. I had to make some modifications to allow passing through v8 options.

TODO

• Migrate debug option parsing
• Make sure the --icu-data-dir flag works as intended

Questions

1. Is this a direction that we are interested in going?
2. This library throws exceptions in the event a flag that requires an argument fails to validate. So, it requires removing the -fno-exceptions flag. Is that acceptable?

In general, I would appreciate any/all feedback to see if this is something that should be pursued.

[silverwind]

My gut feeling tells me that if you have to modify the parser, it may not be the right tool for the job. What were the issues with the v8 options?

Generally, I'm +1 for a better parser that can take arguments in any order.

[evanlucas]

The only change made was to allow getting the unmatched flags. Otherwise, we would have to define all of the v8 flags individually :/

[bnoordhuis]

This library throws exceptions in the event a flag that requires an argument fails to validate. So, it requires removing the -fno-exceptions flag. Is that acceptable?

I'd say no. If nothing else, it's going to add several hundreds of kilobytes of mostly unused unwind info to the binary.

You could work around that by breaking out the option parsing code in node.cc into a separate file and only enabling exceptions for that particular file. You probably have to turn it into a separate static_library target for that to work.

Also, 5,000 lines of mostly unvetted code... surely there must be something simpler?

[evanlucas]

Maybe something more getopt-like?

[Fishrock123]

@bnoordhuis mentioned two options here: #1691 (comment)

[Fishrock123]

See also #1197

[evanlucas]

I guess the biggest difficulty I'm seeing is distinguishing between v8 arguments and arguments that should be in argv vs exec_argv. Not sure how trivial of a task this is going to be. I also see moving this from the current implementation to have breaking changes.

[evanlucas]

closing in favor of #1804