tools: Ambiguity in option names

[tombentley]

Originally created at Fri, 15 Feb 2013 10:16:59 GMT in ceylon/ceylon-common#29:

At the moment the option parsing is very strict about the order of options with respect to the tool it belongs to. For instance the top level ceylon tool (the one which runs subcommands) accepts a --stacktraces option, so

ceylon --stacktrace compile ...

is ok, but

ceylon compile --stacktraces ...

is not. Likewise for (sub)*tools.

The benefit of this is I can later add an option to a tool without it conflicting with options of sub- or parent tools. The drawbacks are:

• it's really not very user friendly,
• it's not even obvious and
• conventionally the order of options shouldn't matter.

So I think we should change it. To do so, we'll need a way to add options to the top level tool without causing conflicts with subtools.

[quintesse]

Originally commented at Fri, 15 Feb 2013 10:48:03 GMT:

To be honest, I don't think we should worry about enforcing that one way or the other. Almost all tools will be made by us, certainly now, so we just elect not to have conflicting names. If in the future people start making their own tools there might come a time where this becomes more relevant, but I don't think the toplevel tool will need many more options so the chance they'll conflict is not too great. For now I'd just not worry about it and just say: toplevel tool comes first, if a subtool has the same option... change the subtool