Implement command line options parser on all supported platforms

[GoogleCodeExporter]

In wiki
http://code.google.com/p/mdsp/wiki/FuncSimDesign#Command_line_arguments
there is a description of all command line arguments that our model should 
handle.

Class config.cpp is responsible for handling the arguments. It should be 
extended to support all the arguments described.

Please use certain "standard" libraries for the solution. It is libgetopt on 
Linux and ??? on MS VS.

Original issue reported on code.google.com by grigory....@gmail.com on 13 Nov 2010 at 8:06

[GoogleCodeExporter]

It would be nice if we used Boost libraries for cross-platform handling of 
command line arguments. 

http://www.boost.org/doc/libs/1_44_0/doc/html/program_options/overview.html

This might be a bit of overkill for our project at first glance, but learning 
how to work with such common and wide-spread library is a good experience.

Original comment by grigory....@gmail.com on 16 Nov 2010 at 11:08

[GoogleCodeExporter]

Original comment by ikile...@gmail.com on 1 Dec 2010 at 9:43

• Changed state: Started

[GoogleCodeExporter]

First, have a look on the comments at the revision page.
http://code.google.com/p/mdsp/source/detail?r=467

Second, this is really a good work you've done - I was able to build funcsim in 
MSVS 2008 in ten seconds from your branch and no manual reconfiguration was 
required!

Now, some more comments on things  that yet should be done.

1) There is one command line option that I forgot to mention but which is 
present in almost all programs I know so far. It is --help, -h . And it prints 
brief help on command line options of a program and then exits. Moreover, when 
an unknown (or bad) switch is encountered, then this help message is shown too. 

It is generally used to have function usage() that prints this message and 
exits the program.

So, this is how it should work:

- Try to parse command line options.
- If it failed, call usage()
- If it succeeded, and '--help' option was given (no matter what other options 
were), call usage()
- Continue working as usual.

2) In r469 Vladimir added some rudimentary command line option parsing for 
looking for number of steps. When you'll be updating your branch and preparing 
for a merge to HEAD you'll have to overwrite this part of his changes. Be sure 
to reconnect the '--numsteps' switch with new scheduler. And there will be the 
chance of conflicts during merge, but don't be scared - TortoiseSVN has good 
option 'edit conflicts' which helps to understand and fix the problems.

Original comment by grigory....@gmail.com on 2 Dec 2010 at 8:19

[GoogleCodeExporter]

1. I'll make Makefile that will understand which system there is today or 
tomorrow because I need to compile Boost on CygWin.

2. Help added.

3. Scheduler added to branch.

Also, adding something to TortoiseSVN is hell with 1000 headers — if there is 
little error, you should make some unobvious movements.

Original comment by ikile...@gmail.com on 2 Dec 2010 at 10:31

[GoogleCodeExporter]

(new files were not added)  that was introduced with previos commit by
Valdimir Dubihin.

Yes, that sometimes happens with me too. I wonder if there is "test commit"
function, like it is done for merge and switch operations.

Original comment by grigory....@gmail.com on 2 Dec 2010 at 10:55

[GoogleCodeExporter]

Should I ask for code review?

Original comment by ikile...@gmail.com on 2 Dec 2010 at 6:00

[GoogleCodeExporter]

Sure, it you think that you have done all you wanted for this task and plan
to merge to HEAD. Until that moment you need not to request a review.

By the way, have you tested that your code at least builds on all Linux
variants and CygWin?

Original comment by grigory....@gmail.com on 2 Dec 2010 at 6:56

[GoogleCodeExporter]

I tested it on

1. MS VS Studio 2008
2. Ubuntu 32-bit
3. Ubuntu 64-bit
4. Cygwin_NT-6.1 (Windows 7)

Original comment by ikile...@gmail.com on 2 Dec 2010 at 6:57

[GoogleCodeExporter]

As the build problems are finally solved, you are allowed to continue with 
review-test-merge process. Be sure to perform all the steps to make certain 
your change won't break anything.

Post updates to your branch and to the code review. *Describe all the steps you 
performed to test your branch in comments to the issue*

Original comment by grigory....@gmail.com on 8 Dec 2010 at 8:39

[GoogleCodeExporter]

Original comment by ikile...@gmail.com on 8 Dec 2010 at 7:01

• Changed state: Fixed