Args parsing about openrhythm

[mdsitton]

Yeah i have been looking at various options for this for a little while now but never really got to comparing the different options very well.

[Salamandar]

Well i searched the different existing libs and this one seems the easies to use !

[Salamandar]

You can define " hard-coded" args in an array, plus parse manually other args

[mdsitton]

Honestly I don't like the syntax of any of the major options out there.
The syntax of this parser is pretty cool though:
https://github.com/aardvarkk/argh

[mdsitton]

If we have to I don't mind just implementing my own lol. They aren't very complex to do honestly. I could also just fork that one and throw it into our codebase and clean it up a bit. :P

[Salamandar]

Sure, I wanted to write my own lib too, and also for configuration files. But hell, there are so many good libs out there ^^

[mdsitton]

Well for config files i was wanting to use json or YAML.

[mdsitton]

We should probably make another issue about config files

[mdsitton]

ok issue #15 is for config files and the config system

[Salamandar]

Great !

[Salamandar]

I checked out Argh, seems cool, the syntax is pretty clear. But there are some problems :

• no apparent support for "bad args"
• only "dynamic" args definitions, can't use a header to define the args (header parsed for the html doc :p )

[mdsitton]

I dont really want to use Argh because its not really a well used library, and if thats the case i'd just rather do something ourselfs. But I mainly just mentioned it as a example of some nicer looking syntax :P

[Salamandar]

Hmm on the other hand OptionParser let us do a lot of job. I have to parse myself the integer args… :p

[Salamandar]

To be fair I think I'm gonna rewrite optionparser x)

[mdsitton]

One thing though what did you mean by "bad args"?

[Salamandar]

Well there are two things : "non-options" (things not preceded by -- or --option ) such as filenames for gcc, and unknown options. Argh does not seem to support "out of the box" neither of them… And it does not support parameters for short options.
Anyway, i've almost finished to rewrite OptionParser.

[mdsitton]

@Salamandar So how is this going, you said you were going to write your own parser(or rewrite the other one)

[Salamandar]

Well it's going fine, I just had a really big existential issue about if it was relevant or not ^^

[Salamandar]

Finally OptionParser is just too overkill. TCLAP is pretty good (I just wrote a PR to TCLAP and may write a second to support multiple one-char flags for an option).
The work in the commandline branch is just a draft because I'm working on my laptop this week :p

[mdsitton]

My problem with TCLAP is that it is largely unmaintained. Last release was 2011, last commits were 2015, and the page even says that it will likely not be developed any further.

[Salamandar]

Yeah that was my issue too. But some widely libs are unmaintained too. TCLAP does not seem buggy, and the authors seem quick to answer on sourceforge even if it's "i don't have much time but please make a patch !"

[mdsitton]

I still don't mind rolling our own

[Salamandar]

Well I think I'm gonna fork TCLAP on Github (and tell the original authors about it) so we can restart dev on it.

[Salamandar]

Finished with PR #32. Closing, we'll solve the possible problems in the PR.