My favorite command-line parser for Rust:

https://github.com/blyxxyz/lexopt

I.e. it does not create command-line for you and you can fully control of the user experience.

@jarkko nice, I might try it for my next project.

@Aissen I was looking for something where I get some robustness but fine-tune the cli usage for tpm2sh :-) It does the job for me.

@Aissen i also migrated to json from serde_json for the sake of simplicity and clarity (for me that mainly simplicy and clarity of the binary). i'm constantly trying to find dependencies from tpm2sh that do less rather than more and have less recursive dependencies :-)

thinking more of the binary also improves productivity in long-term investment as linking times go much lower, which is like the main bottleneck when compiling rust. you can easily get a high-end ryzen workstation melt on that process if you are sloppy with deps :D (i've got my 9950X workstation OOM because of that on some projects).

@Aissen ... because as we know linking tends to be more core consolidated drilling (there's been some excellent work to overcome this recently tho)

@jarkko agreed, if you don't use serde features (derive macros, etc.) or need high performance, it's better to think of developer experience and get shorter compile times without serde. But for now you're not syn-free, right? Did you save enough on compile times ?

@Aissen sorry, what does "syn-free" mean? :-)

I just tagged 0.7.0 version you can check up yourself: https://github.com/puavo-org/tpm2_library

crypto crates add up a bit for tpm2sh but i want consolidate enough of that so that i can use this for e.g. kernel testing w/o having to use openssl too much

when i started to make tpm2sh it was this cover letter that i used as my source for minimal set of features that i need :-)

https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/

@jarkko syn is a crate that allows macros to parse rust code accurately at build time - a feature that is not provided by the language.
It's often responsible for a lot of the build time. serde depends on it for example, but so do many other crates, many of which are in tpm2sh:
- rstests
- pest_derive
- tracing

@Aissen ah OK. for protocol i have standalone test program that outputs kselftest exit codes. For that subcrate I keep even dev-dependencies absolute zero.

tpm2sh is playground for testing that care but still i try to decrease its size when i find something where i can slim it down :-)

@jarkko for example, with `cargo build --timings --release --workspace` : syn is #6

@jarkko I know, I was replying to you getting rid of serde_json, which was only used in tpm2sh 🙂

@Aissen thanks totally new command-line options for me :-)

@Aissen yeah true :-) i'm actually looking forward to get rid of json. i already gave on json structure for pcrs as i can parse tpmlpcrselection on fly (or that is like the whole point of this project)

i.e. from json stack a migration is ongoing towards TPM object stack...

@jarkko you might want to look at `cargo tree` too. And the inverse to focus on a single dep (e.g syn):
```
> cargo tree --invert syn -e no-dev
syn v2.0.104
├── pest_generator v2.8.1
│ └── pest_derive v2.8.1 (proc-macro)
│ └── tpm2sh v0.7.0 (/tmp/tpm2_library/tpm2sh)
├── thiserror-impl v2.0.15 (proc-macro)
│ └── thiserror v2.0.15
│ ├── pest v2.8.1
│ │ └── tpm2sh v0.7.0 (/tmp/tpm2_library/tpm2sh)
│ ├── pest v2.8.1
│ │ ├── pest_derive v2.8.1 (proc-macro) (*)
│ │ ├── pest_generator v2.8.1 (*)
│ │ └── pest_meta v2.8.1
│ │ └── pest_generator v2.8.1 (*)
│ └── tpm2sh v0.7.0 (/tmp/tpm2_library/tpm2sh)
└── tracing-attributes v0.1.30 (proc-macro)
└── tracing v0.1.41
├── tpm2sh v0.7.0 (/tmp/tpm2_library/tpm2sh)
└── tracing-subscriber v0.3.19
└── tpm2sh v0.7.0 (/tmp/tpm2_library/tpm2sh)
```

The whole project has been about doing placeholder solution and then rewriting it. I even "rewrote" tpm2_protocol twice, first I thought it was fine when I got it working on static objects. Then I realized that I need to do things from ground up again tweaking the implementation from every possible location to make it robust enough with lifetimes to be able to use TpmObject as dyn trait.

But yeah, this is something I knew that would happen when aiming for product quality first time in Rust :-) It was a time investment really. I learned so much from this that I cannot really even begin to describe it ...

@Aissen I've been thinking a bit to use ring for crypto in future just to get some defacto crypto solution that is not openssl.