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!

2 Likes
#14

@utkarsh.ayachit Did you get around doing this? Would it make sense to add this to VTK? I want to add a small executable in VTK that would benefit from using a options library. Now I use cxxopts but I could easily switch.
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7938

#15

nope. I didn’t…would be nice you or someone has time to add CLI11 as TPL to VTK.

#16

Thanks, I ended up not adding that executable so I don’t need an option library in VTK anymore, but it may still be useful to have it there instead of ParaView.

#17

I am late to this conversation, but I want to add Boost.Program_options library to the debate. The main advantage of using this instead of the previously mentioned libraries is that is part of Boost library meaning that its well documented, known and it has a good change to eventually make it to the standard library.

#18

I can’t recall exactly why, but we’ve stayed away from making boost a required dependency of VTK/ParaView.

#19

IIRC it is because boost is often just a huge pain to build.

#20

Yeah, that’s true, especially for small libraries, boost building system is overkill. It uses its ad-hoc compiling scripts which is probably due to licensing issues.

On the other hand if the library is small enough we could cmakify it, hoping that it does not depend on another boost library (which depends on another boost library…) which maybe not worth the effort and more important: its maintanance.