Skip to content

Conversation

silverweed
Copy link
Contributor

We now have enough C++ executables (with more to be ported) to justify sharing some code between them, in particular option parsing.

This PR introduces a simple option parser class that covers most of our cases. Not all cases (e.g. hadd keeps its custom parsing because it's a bit weird), but it's already enough to cover rootls and rootbrowse, and will in the future also cover rootcp, rootmv etc.

The parser is documented with code examples and properly tested and it's about 300 lines of codes (about an order of magnitude less than e.g. cxxopts which in my opinion is overkill for our use case).

Checklist:

  • tested changes locally
  • updated the docs (if necessary)

Copy link

github-actions bot commented Oct 9, 2025

Test Results

    16 files      16 suites   2d 16h 19m 7s ⏱️
 3 664 tests  3 663 ✅ 0 💤 1 ❌
58 053 runs  58 052 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit 3e4fe8b.

♻️ This comment has been updated with latest results.

Copy link
Member

@pcanal pcanal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (Beside the comments and portability issue)

@ferdymercury
Copy link
Collaborator

Thanks a lot for the initiative!

Even if it's 300 lines of code, isn't it better to rely on something external that gets auto-maintained, even if it's bigger in number of lines of code?
Such as the header-only https://github.com/CLIUtils/CLI11

Or to understand better the motivation, what do we gain by having a small parser for which we have to add our own tests?

  • Is it because then compile time is smaller?
  • Or is initialization time more performant?
  • Or is the overkill of CLI11 or cxxopt increasing the size of the produced binaries or sth like that?
  • Or to not rely on external sources?

@silverweed
Copy link
Contributor Author

Thanks a lot for the initiative!

Even if it's 300 lines of code, isn't it better to rely on something external that gets auto-maintained, even if it's bigger in number of lines of code? Such as the header-only https://github.com/CLIUtils/CLI11

Or to understand better the motivation, what do we gain by having a small parser for which we have to add our own tests?

* Is it because then compile time is smaller?

* Or is initialization time more performant?

* Or is the overkill of CLI11 or cxxopt increasing the size of the produced binaries or sth like that?

* Or to not rely on external sources?

It's mostly the last point (though the first is also somewhat important).
Simply put, if the functionality is not particularly complex (as is this case) it's always better to have your own code that you know what it does and can easily control than an external dependency that you need to maintain and complicates your build system.
Furthermore, if such dependency is 10x the code size (without providing at least 10x the benefits) then you would just be carrying around much more weight than you really need.
External dependencies are not free and should only be used where there is a really good argument for them, which in this case I don't see.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants