Introduce C++ Commandline Argument Parsing Library?

Next Generation ROS
1

I’ve been writing a few apps in https://github.com/ros2/demos - and found myself duplicating a lot of code for argument parsing to make the applications easy to use and understand. I am wondering if there’s a generic need for a “recommended/provided” argument parser for C++ applications in the ROS2 stack. Something with the same ease of use as Python’s https://docs.python.org/3/library/argparse.html

Two options I’ve been considering:

I personally prefer the second option, since it already exists, but I’m not sure how one might go about adding such a dependency.

Any thoughts or opinions on this?

1 Like
2

Specifically for the demos packages, I wonder if dog-fooding ROS parameters might be a better alternative. If they’re inconvenient for us to use then we need to improve them more. Many of the demos were created before parameters were viable for this use case so maybe we should reevaluate them. This may not address all of the cases, however.

Most likely we’d still use arguments in a few places, so it wouldn’t be terrible to have some go to library for that kind of thing. What we have now is just a stop gap measure.

I’d also prefer to bring in an external dependency, as long as it’s not enormous (e.g. I would be wary about importing Boost just for Boost.program_options). I wouldn’t implement something custom in rcpputils simply because there are so many small, focused libraries out there that do this already.

As for how, if it’s header only, we could put it in rcpputils (I’ve “vendored” header only things like this before, e.g.: https://github.com/osrf/osrf_testing_tools_cpp/blob/afe870ca9f37fb006e0cf2c5f4ceda696ab08b32/osrf_testing_tools_cpp/include/osrf_testing_tools_cpp/variant_helper.hpp#L39). Otherwise, we’d probably want to make it a separate vendor package, e.g. like https://github.com/ros2/yaml_cpp_vendor. If it has Ubuntu and Homebrew packages of the appropriate version we could use that and make a choco package for it.

3

That’s a good idea for this use case - but I also agree that

Sometimes they’re just the best way to interact with commandline tools :slight_smile:

What are your thoughts on git submodules, vs. copying it in there? I do like the cxxopts library (and it’s header-only), and it does seem like a popular alternative to Boost.program_options for those who don’t want to invite Boost in.

4

It should still be a separate vendor package (if it is not already packages across all targeted platforms).

5

As @dirk-thomas said, a separate package is mostly likely appropriate here if the user is going to use it directly (as is the case here I think).

If you were to copy into another package, for some reason, I tend to prefer subtree to submodule, as submodule just has so many issues in my experience.

In this case I agree a separate cxxopts_vendor would be best, but in other cases, I think it can be appropriate to include a header only thing into something like rcpputils (especially if it is not exposed directly to the users of rcpputils, like if we were going to wrap it in our own API).

6

For this library I haven’t found any packages - if we decide to use it, it would need to be vendored.

For this case I don’t think I’d vote for going that route, based on the (probably) limited usage. In general I figure ROS2 code is targeted at non-dev-machine devices and be configured via rosparams instead of being CLI tools, but like you said, it wouldn’t be terrible to have a go-to when we need it.

I’m going to do a little proof of concept with a cxxopts vendor package and migrating some C++ demos to use it, then see how that looks/feels. Thanks for the input!

1 Like