tools: Ambiguity in option names

[CeylonMigrationBot]

[@tombentley] 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.

[Migrated from ceylon/ceylon-common#29]

[CeylonMigrationBot]

[@quintesse] 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

[CeylonMigrationBot]

[@quintesse]

conventionally the order of options shouldn't matter

Well it seems "complex" commands like git have the same limitation. And in fact it doesn't even allow long form options without an =. (To be honest I think we've made our lives needlessly difficult when we decided to allow that. It's hard to avoid ambiguities)