Command line argument parsing

Development
#1

Is it time to rework the command line parsing to be bit cleaner? The current vtkPVOptions implementation is quite dated.

cxxopts seems like a very elegant choice. It also has mechanism to group options into categories, thus making it easier to parse --help output. Here’s an output from an another test program using cxxopts

> ./demo --help
Usage:
  ./demo [OPTION...]

  -h, --help  help

 Mode options:
  -s, --server  run as server
      --hybrid  run as client and server

 Client options:
  -u, --url arg  address for server to connect to (default:
                 ofi+tcp;ofi_rxm://192.168.0.23:37585)
1 Like
#2

+1 for cxxopts !

We are using it at F3D. Well, a slightly modified version for our needs, and are quite happy with it.
We especially like the way it handles defaults values / no values, letting us use this kind of mechanism :

demo --activate-option : run and activate an option with a default value
demo --activate-option=value : run and activate an option with a user provided value

In the case of ParaView, that would remove the need for --stereo-type for example.

It means however that ParaView will loose retro compatibility with old scripts, so we may need to provide a CMake-enablable compatibility/deprecration layer for a few versions.

#3

FYI @Michael @Joachim_Pouderoux

#4

+1 from me. I have a few examples in the VTKExamples that will really benefit from this. It will benefit many users, especially for those coming from a Python background where this is second nature.

#5

Good point! We should probably add it to VTK itself and update tests/examples to start using it too.

#6

I like cxxopts. The one thing I can recall is it needs support for gcc 4.9 or greater. If I recall correctly you currently support gcc 4.8.5 with 5.8.0. Might be an issue as I know a few folks still use 4.8.5 with ParaView given the latest round of issues when 5.8.0 came out.

#7

good point. I don’t think this will be happening for 5.9, maybe 5.10 at the earliest. By then we may be able to revise the minimum supported gcc versions.

1 Like
#8

I was looking at cxxopts a while back, it has trouble with negative positional parameters. e.g.

demo -1 12

However this is solvable by putting optional parameters first and using -- before the positional parameters e.g.
e.g.

demo -r -- -1 12

This means the user has to know this, it stumped me at first. See: https://github.com/jarro2783/cxxopts/issues/254

#9

Do also consider CLI11, this is much closer to the same behaviour as argparse and allows really complex inputs (if needed). It is also available as a single header. The license looks to be similar to the old VTK license, so there is probably no issues there.
It is very easy to use e.g.

// ...
  // Initialise the ArgParameters
  ArgParameters ap{true, 3, -45};

  CLI::App app{GetProgramName(argv[0]) +
               " - testing positional command line options"};
  bool r = false;
  app.add_flag("-r, --radians", r, "Use radians");
  app.add_option("angle", ap.angle, "The angle", true);
  app.add_option("dp", ap.dp, "The decimal precision", true);

  CLI11_PARSE(app, argc, argv);

  ap.degrees &= !r;
// ...
2 Likes
#10

I am going to resurrect this topic. We will be tackling this in near future.

Looking at CLI11, I do like the subcommands. I can see how ParaView-based applications could use that to separate their app specific cmd-options and cmd-options to pass on to the ParaView engine.

What do folks think? Is there a general preference? Since cxxopts and CLI11 are both robust choices, I think it simply boils down to what we as developers prefer. If the developers are more familiar with one over another, I think it may be wise to just stick with the familiar one. Is there are general preference among the developers?

2 Likes
#11

familiar with cxxopts here, but not closed to CLI11 at all.

#12

cxxopts requires gcc 4.9+ and above, but ParaView requires only gcc 4.8+, and I expect it will need to support it for some time. CLI11 supports gcc 4.8+

CLI11 looks like it has just about everything we could need.

#13

Based on the comments and the fact that CLI11 supports subcommands which potentially may be a very nice way to support custom applications / paraview-variants, I think I’ll proceed with CLI11.

thanks, everyone!

1 Like