Re: gengetopt, anyone?
On 10/01/11 16:16, Reuben Thomas wrote: I notice no-one mentioned argp. (I also notice one of autoopts's testimonials says that it (autoopts) is simpler than argp!). But from a quick look argp seems rather neat; it doesn't need a separate parser and code generator, and it's available in gnulib. Why aren't I using it? Because there are too many things it doesn't deal with? http://www.gnu.org/software/autogen/compare.html http://www.gnu.org/software/autogen/autoopts.html There are really two parts to option processing: 1. computing option state, derived from configuration files, environment variables and the command line options themselves, but also: 2. documenting them and ensuring consistency between all the various documents and what the code actually does. (You may not like man pages, but they are the standard way of conveying program usage) Only two do both.
Re: gengetopt, anyone?
Hi Reuben, I notice no-one mentioned argp. (I also notice one of autoopts's testimonials says that it (autoopts) is simpler than argp!). But from a quick look argp seems rather neat; it doesn't need a separate parser and code generator, and it's available in gnulib. Why aren't I using it? If you mean to ask why are so few people using argp, here's the answer why I'm not using 'argp' in GNU gettext, GNU libiconv: 1) When I introduce a new option, I have to do 5 modification: - Add a variable that captures the value of that option. - Implement the semantics of the option. - Change main() and the getopt_long call to set said variable. - Update the usage() message. - Update the documentation. AFAIU, 'argp' would allow me to combine 2 of these 5 steps, leaving only 4 steps. But 4 modifications is not much of a simplification over 5. On the other hand, 'argp' has some complexity. I feel already saturated with getopt_long's complexity. 2) The 'argp' in glibc has some problem with internationalization, whereas the 'argp' in gnulib doesn't (fixed by Sergey on 2006-09-09). Quite confusing. Bruno -- In memoriam Bartolomé Blanco Márquez http://en.wikipedia.org/wiki/Bartolome_Blanco_Marquez
Re: gengetopt, anyone?
Reuben Thomas r...@sc3d.org writes: I notice no-one mentioned argp. (I also notice one of autoopts's testimonials says that it (autoopts) is simpler than argp!). But from a quick look argp seems rather neat; it doesn't need a separate parser and code generator, and it's available in gnulib. Why aren't I using it? I used argp for several projects long time ago (and worked on the initial import of argp into gnulib). My experience was that the code needed to support argp ended up being around the same size of a hand-written parser a'la coreutils without its flexibility. In contrast, using gengetopt leads to less per-project code that I have to maintain. This is a better trade-off for me. (At least in theory, my issues with the gengetopt --help output results in the gengetopt code in Libidn is still larger than I would want.) /Simon
Re: gengetopt, anyone?
On Sat, Oct 1, 2011 at 6:16 PM, Reuben Thomas r...@sc3d.org wrote: I notice no-one mentioned argp. (I also notice one of autoopts's testimonials says that it (autoopts) is simpler than argp!). But from a quick look argp seems rather neat; it doesn't need a separate parser and code generator, and it's available in gnulib. I very much like argp and have used it in several projects. I find the amount control possible for --help formatting to be refreshing compared to many other option processing libraries. I also like (though have not used) it's ability to provide reusable options processing building blocks. - Rhys
Re: gengetopt, anyone?
I notice no-one mentioned argp. (I also notice one of autoopts's testimonials says that it (autoopts) is simpler than argp!). But from a quick look argp seems rather neat; it doesn't need a separate parser and code generator, and it's available in gnulib. Why aren't I using it? -- http://rrt.sc3d.org
Re: gengetopt, anyone?
Reuben Thomas wrote: I've just been playing with gengetopt. There's a lot to like: it gives me (potentially multi-language) options handling for one line per option (plus any extra text I want) in a simple .ggo file, and half a dozen lines of code (four of which really should be redundant as they test the help and version flags and call the relevant display routine). All the necessary variables to signal which options are set and their values are defined for me. The only thing really not to like is that for my simple six-option program it generates 565 lines of C. My program is only 140 lines, representing a roughly 500-line net addition when I use gengetopt. I'm not inclined to worry that much, but it does seem a lot. There's also a slew of minor issues, mostly cosmetic, and all easy to fix, for which I've filed a dizaine of bug reports and offered to fix myself. It should not go unremarked that gengetopt is big on gnulib (though one of the bugs I filed is that its manual overenthusiastically documents how to add gnulib to a project!). Has anyone else any experience with it? It would seem to have applications in, for example, coreutils, though its use would obviously be a fair amount of work and the quantity of code it generates might be more of a concern. Hi Reuben, a fair amount? British understatement, surely ;-) I suspect that you'll find many exceptions. If we were starting coreutils development now, I'd be much more inclined to use it, but it seems like the minimal benefit from that sort of large-scale factorization would not be worth the effort. [not even considering code size issues]
Re: gengetopt, anyone?
Reuben Thomas r...@sc3d.org writes: Has anyone else any experience with it? I have used it in libidn, gsasl and a few other projects since well over 5 years. I have been quite happy with it. The biggest concern I have had is that the auto-generated --help screen is impossible to fine-tune and it doesn't look as good as I want it to. For Libidn, I have given up on using the auto-generated --help output and instead wrote a custom function for displaying it. For gsasl I still use the auto-generated screen, mostly due to the much larger amount of parameters. One of the things I want to go away is that it prints the project name and version as the first line of --help, I think there is no point in having that there (there is --version after all) and I would prefer a terse Usage:-line instead. /Simon
Re: gengetopt, anyone?
On 27 September 2011 14:49, Simon Josefsson si...@josefsson.org wrote: The biggest concern I have had is that the auto-generated --help screen is impossible to fine-tune and it doesn't look as good as I want it to. Most of the bugs I have filed and offered to fix are precisely to do with making the details of the help display match coreutils grep better. -- http://rrt.sc3d.org
Re: gengetopt, anyone?
On 09/27/11 06:49, Simon Josefsson wrote: Reuben Thomasr...@sc3d.org writes: Has anyone else any experience with it? I have used it in libidn, gsasl and a few other projects since well over 5 years. I have been quite happy with it. The biggest concern I have had is that the auto-generated --help screen is impossible to fine-tune and it doesn't look as good as I want it to. For Libidn, I have given up on using the auto-generated --help output and instead wrote a custom function for displaying it. For gsasl I still use the auto-generated screen, mostly due to the much larger amount of parameters. One of the things I want to go away is that it prints the project name and version as the first line of --help, I think there is no point in having that there (there is --version after all) and I would prefer a terse Usage:-line instead. I have also played with it, and tried to combine my autoopts strengths with Lorenzo, but he seemed pointedly uninterested. In the end, there is little gengetopt does that is not well covered by autoopts: http://www.gnu.org/software/autogen/compare.html and it is more easily covered in autoopts. WRT fair amount of work, I'd have to agree with Jim. It is an understatement. The problem being that since each program basically parses its own options (getopt() and getopt_long() being only very minor assists), and has non-standard-isms in the way they are handled. You'd have to go back to the generator engine and add a lot of exceptional handling code. Not worth it. BTW, current NTP code uses autoopts for handling its options and configuration files and multi-flavored man pages. Cheers - Bruce
