[gnutls-devel] GnuTLS | tools in src/ should not use libopts for parsing cmd line options (#775)
Development of GNU's TLS library
gnutls-devel at lists.gnutls.org
Sun Jun 2 18:09:36 CEST 2019
Tim Rühsen 🛠 @rockdaboot wrote
[...]
> Do you know of alternatives?
No, I had searched in vain multiple times. I have found myriads of C option parsing libraries, but many are orphaned and none of the ones I looked offered the autogeneration of docs as autogen did. (A typical example is gengetopt: It can produce manpages, but they are very bare-bone, and it is also dead upstream.)
> When adding/changing command line options within the C sources, the man pages and texinfo file should automatically be updated.
>
> This MR does it the following way:
>
> build the tool
> execute the tool with a special option
> inject the output from the tool into a markdown template
> use pandoc to generate manpage and texinfo from the resulting markdown file
>
> The workflow allows the developer to just work on the C code (adding an array entry and doing the implementation). No manual editing of texinfo, no out-of-sync of implementation and documentation ever again.
That sounds very sensible and similar to the current solution. Thank you! (FWIW I think that moving away from autogen is something that will need to happen at some point, since it is a single-author project and upstream activity is declining.)
Regarding markdown to man and/or texinfo converters: The alternatives are rare. ronn needs ruby and only does manpage output. lunamark (lua) might have been a candidate, but it is not even packaged for Debian.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/775#note_177011656
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190602/34bd9683/attachment-0001.html>
More information about the Gnutls-devel
mailing list