[Development] Qt Playground - Command Line Parser experiment

[Hugo Parente Lima]

On Thursday 15 March 2012 09:23:27 marius.storm-olsen at nokia.com wrote:
> On 15/03/2012 04:53, ext David Faure wrote:
> > On Monday 12 March 2012 20:06:22 marius.storm-olsen at nokia.com wrote:
> >> Anyways, something to keep in mind when working on your
> >> implementation. It's a can of worms with a lot of bikeshedding ;)
> > 
> > Yes, this has been said a few times already. However I don't think
> > this is enough of an argument for not doing anything about this in Qt
> > (I know for a fact that your email discouraged Laszlo of even
> > trying).
> > 
> > If the message, upfront, is "you won't be able to get this into Qt",
> > then a natural reaction is to just say "OK, then I give up, we'll do
> > something KDE- specific instead". But this goes against my main goal
> > of removing the distinction between a KDE app and a Qt app as much as
> > possible.
> 
> I'm sorry if it discouraged Laszlo from trying to embark on this
> project. Nowhere in my email did I say that it couldn't or shouldn't be
> done, nor that it wouldn't be accepted in Qt.
> 
> My arguments underlined why this task/project is _special_, and why I
> believe that it would fit better as a separate AddOn repo, than a
> feature branch to qtbase.
> 
> I think development and adoption would happen more quickly if the
> project has its own AddOn.
> 
> Also, with an AddOn it doesn't matter much what other people say. If you
> don't want it/agree with it etc, then you simply don't include it.
> 
> > I see no reason why command-line argument parsing can't be provided
> > by Qt. It's not as complex as you say, all kde apps do fine with the
> > features listed at http://api.kde.org/4.x-api/kdelibs-
> > apidocs/kdecore/html/classKCmdLineOptions.html#ac3064e6ec33f92a4a6d17eb8f
> > f766034
> 
> I'm not saying that it cannot be provided for Qt. I'm saying there are
> many opinions on how an argument parser should work, so do it in an
> Addon first. Then it doesn't matter so much if not everyone agrees. It
> might be harder if you don't get broad agreement when working on a
> feature branch of QtBase (say if Lars or Thiago say no), then you cannot
> merge and the work is in limbo.
> 
> And nothing says we cannot pull it from the Addon into QtBase at a later
> point in time.
> 
> > You're right, tar couldn't use this. But then again, tar is not a
> > Qt application, and will probably never be. And for a new program,
> > there's always the option of *choosing* a set of command-line options
> > that is actually doable with the existing Qt class, rather than going
> > for something as funky as "tar xvf". Look at GNU getopt: same issue,
> > it can't be used by tar. So what?
> 
> The applications I mentioned are "bastards" when it comes to
> commands/actions/options, and I mentioned them on purpose to facilitate
> discussion. They don't represent valid use-cases, but rather indicate
> the extremes. It's a balancing act though, to figure out which features
> to support, and which ones to ignore to capture the 90% without getting
> too complex.

Answering according to what I implemented 2 months ago and is on github:
 
> For example:
> * Do short options only accept single letter, or can they have more?
>      -E for preprocessing in GCC, /E or /EP with MSVC
>      -reverse for Qt apps

You must have a clear definition of what is a short option then, if you mean 
options that doesn't require a value, ok, it's supported. sorry if I didn't 
get what you meant.
 
> * Will 'single dash' long options be allowed?
>      -traditional-cpp in gcc
>      -style=foo for Qt apps

Yes, it is.
 
> * Will short option clustering be allowed? What if short options support
> more than one letter?

Option clustering is allowed.
If the short option has more than one letter it isn't short.
 
> * What if the clustering of some short options match another single
> short option, or a long option if single dash long options are allowed?

IMHO it's a programmer failure to support: -a, -b and -ab
IIRC in my implementation the class tell the user used all options.
 
> * Do you allow for turning on/off boolean values with preceeding +/-?
>      MSVC uses trailing '-' to turn off options, like /GR- to
>      turn off RTTI

Isn't implemented, but it easy to do, anyway I don't know other application 
besides cl.exe that users this pattern.
 
> * Do you use space, '=', ':' or nothing as a option/value separator?
>      -o<filename>
>      -output <filename>
>      -output:<filename>
>      -output=<filename>

The current implementation accepts space or "=" as separator, add support for 
other separators should not be a hard task.
 
> There's lots of nuances to evaluate. You could say lets just support
> getopt, but then you're likely falling into the unix-world-only trap.
> But I guess, "so what"? ;)

Yes, there are, IMO we just need good defaults and some flexibility without 
complicating the API for ultra-corner cases.

-- 
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120315/051fcba4/attachment.sig>