The previous `%choices` string no longer works since cpp-optparse got updated. In a confusing turn of events, I believe cpp-optparse got renamed to cpp-argparse at some point in history, and a new cpp-optparse repository was made in its place as a fork of argparse before `%choices` was added to it, and picked up development without ever adding `%choices`. This lead to the breaking change not being documented anywhere in the commit history.
Showing it as a metavar matches the style of many GNU tools, this is how it renders:
```
$ ./Binaries/dolphin-tool verify -h
Usage: verify [options]...
Options:
-h, --help show this help message and exit
-u USER, --user=USER User folder path, required for temporary processing
files. Will be automatically created if this option is
not set.
-i FILE, --input=FILE
Path to input file.
-a crc32|md5|sha1|rchash, --algorithm=crc32|md5|sha1|rchash
Optional. Compute and print the digest using the
selected algorithm, then exit.
```
Also we were lying about RVZ being a default value in the convert command.
Yellow squiggly lines begone!
Done automatically on .cpp files through `run-clang-tidy`, with manual corrections to the mistakes.
If an import is directly used, but is technically unnecessary since it's recursively imported by something else, it is *not* removed.
The tool doesn't touch .h files, so I did some of them by hand while fixing errors due to old recursive imports.
Not everything is removed, but the cleanup should be substantial enough.
Because this done on Linux, code that isn't used on it is mostly untouched.
(Hopefully no open PR is depending on these imports...)
Use "bzip2" instead of "bzip" in optparse's compression choices for the
convert command. This is both more accurate and matches what the
ParseCompressionTypeString function expects.
The mismatch between the two parsing functions prevented compression
using bzip2 because either ParseCompressionTypeString or optparse would
generate an error when using "bzip" or "bzip2" respectively.
Fixes https://bugs.dolphin-emu.org/issues/13427
Previously, we had WBFS and CISO which both returned an upper bound
of the size, and other formats which returned an accurate size. But
now we also have NFS, which returns a lower bound of the size. To
allow VolumeVerifier to make better informed decisions for NFS, let's
use an enum instead of a bool for the type of data size a blob has.
This was requested by a forum user, and I thought why not.
It's a simple change to make since DiscIO already supports it,
and I assume command-line users know roughly what they're doing.
New dolphin-tool command: "header"
-b / --block_size
-c / --compression
-l / --compression_level
Informative RVZ/WIA header2 value "compression_level" is now a s32 instead of a u32, because negative compression is a thing.
Speaking of, it is now possible to use negative compression levels in dolphin-tool's convert command (not the GUI, though).