Am 07.08.2026 um 15:47 schrieb Frank Lichtenheld:
Hi. I think the current format of options.c is a problem. Much of the logic is hidden in C code, difficult to compare to the documentation, and the if-else-if hell is hard to read, even for some parsers (cppcheck is an example for that). When adding new options we always go through the same steps and errors (e.g. forgetting to add usage text). So I would guess most people would be open for something better. But how should that look like? I have been looking into a declarative approach with code-generation. We could document the options in e.g. a YAML document and then generate code out of that. Ideally not a repeat of the current code but something a bit better. I was thinking of an getopt_long-style approach with an array that describes the options.
I agree on that. If that format should be YAML or some other format, I don't have a strong preference but something that is easy to maintain and write would be my favourite.
One limitation of this approach is that clearly this can only describe a subset of the semantics of the options. Many options have too much logic behind their parsing that can not reasonably be expressed in a declarative way. But I think it still would be much preferable to the current state.
I also would not try to put everything such a file. Otherwise you reinvent the wheel (badly) as you tend to develop a crude language to describe. I would aim to be able to express like 90% of the option and the rest gets its own C code like now.
I did some manual tests for both the YAML and the options array and then also let write Claude a full spec based on these ideas. You can find it here: https://github.com/flichtenheld/openvpn/blob/options-schema-doc/doc/options-schema.md The interesting part (and what I have mostly reviewed and improved so far) are the actual example results in section 5 (YAML, https://github.com/flichtenheld/openvpn/blob/options-schema-doc/doc/options-schema.md#5-worked-examples) and section 6 (C, https://github.com/flichtenheld/openvpn/blob/options-schema-doc/doc/options-schema.md#6-generated-artifact-shape) Before going any deeper into this rabbit hole I would be curious if people think this general approach could have merit? Or whether there are other ideas where to take this?
Yes. I would like to have a strong seperation between "data" and "code". Have the generated data format be a static table and have the actual logic/parsing still written by hand similar to the add_option of your github page and just use the static generated data to be able to lookup thing.
I think having to debug/read generated/super complex code to figure out problems is something most of us probably had to do at some point (glib 2.x is a real horror show ...) and I would try to avoid that.
We might not able to fully avoid that but I would try to have the generated code (that has logic) as simple as possible.
Arne _______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel
