Port program_options to cxxopts

[nilsnolde]

Recently I ported a few projects away from boost::program_options to cxxopts. Also here it seems to be the only reason to have a non-header-only boost as dependency. In fact, I just wanted to build osmium-tool from source on CentOS 7 (not my choice), but boost is at 1.53 there. Luckily they changed to then to Ubuntu.

cxxopts is IMO also quite a bit more readable/intuitive and It seems that would make sense here too. You can see a fairly involved example here:

https://github.com/VROOM-Project/vroom/blob/4b898ecc55d3005071e22b327dfe1d253c0d7ba1/src/main.cpp#L29-L95

What do you think @joto ? If you agree, I'd get on a PR.

[joto]

I never really liked the boost way of parsing command line options, so I am willing to consider a switch. I looked at other libraries but never found a great one. From a quick look at cxxopts I am seeing these problems:

1. There is a reasonably new release 3.0.0 that apparently has some incompatible changes to version 2. Debian stable has still the version 2, Homebrew has version 3. So the code will have to work with version 2 and version 3. Ubuntu only got the library with 22.04, so no support for older Ubuntu versions. That's not good. The only option might be to vendor the lib in which I am not too happy about.
2. Osmium needs support for subcommands which I think it doesn't have.

In any case: There are a lot of command line options in osmium. Replacing all this code is a major task and there are not nearly enough tests to cover all of them and make sure everything still works. So there will be a lot of checking needed to make sure everything is okay.

[nilsnolde]

Some good points, thanks @joto . Subcommands could be doable I think, but it's not really an API, it can be coerced to behave like supporting subcommands. The sheer amount of (sub-)commands and the effort involved in testing is a bit frightening, you're right. My issue was maybe a bit of a fast shot after failing to compile on CentOS 7. Didn't try, maybe boost 1.53 would've worked (!?).

As for vendoring, IMHO it's still much nicer to vendor a header-only lib than requiring a pretty heavy compiled lib (boost). May I ask what you don't like about it in this case? I can see a problem if osmium-tool was used as a lib and cxxopts would be a public dependency, then it'd clash in package managers. But in this case I'm mostly seeing the benefit of controlling a dependency from within the project.

[joto]

Vendoring is only the last option if there is no other way. Even simple header-only libraries change and need updates and I don't want to maintain that. That's what distributions and package maintainers are for. Debian, btw, doesn't allow vendored in stuff, but will use what's available in the distribution. So vendoring in stuff, while maybe making it simpler for end users compiling the software themselves, makes it harder for package maintainers.

I'd love to get rid of boost as a dependency, but program options are not the only use (also libosmium needs boost for some things), so that's a different issue again.

[nilsnolde]

Even simple header-only libraries change and need updates

In fact, I interpret it the other way around :sweat_smile: For header-only libraries (esp those only needed at compile time) I much prefer vendoring them, because I don't want to keep up with code changes in the various package manager's releases and control the needed release myself. E.g. Fedora/Arch have quite quick cycles of updating libraries and they're often very close to the latest release. For Valhalla and (compiled) Boost that was such a PITA that I ended up porting all compiled libs to header-only alternatives and vendoring header-only boost (which would be enough for libosmium as well I assume?). But sure, that comes with some overhead, header-only boost is unfortunately only (sorta) reliably available with platform-agnostic (but fail-prone) managers like conan. I tried the header-only boost super-repo, that pulled in > 2 GB of repos haha. That problem might not plague (lib)osmium though, it's just anecdotal. Valhalla is often compiled from source, osmium-tool is targeting package managers more than we are, so I understand that support for that is much more important and if some ancient distro can't have it, it's just part of the OSS "contract".

I never was a package maintainer for any Linux distro and there might be good reasons for it. I can't think of a reason why it shouldn't be "allowed" to vendor compile-time-only libraries which are not publicly exposed to the system.. EDIT: yeah, I guess it's easily a problem for the -dev packages.. I see why it's still a problem.. If Debian doesn't allow that, it would of course be another ax to the idea of cxxopts.