This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Patch to add argument parsing classes to gdb
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Robert Lupton the Good <rhl at astro dot princeton dot edu>
- Cc: gdb at sourceware dot org
- Date: Sun, 13 Nov 2011 11:29:28 -0200
- Subject: Re: Patch to add argument parsing classes to gdb
- References: <412F240F-46E7-4A5C-8207-721E15A58B6D@astro.princeton.edu>
Hi Robert,
Robert Lupton the Good <rhl@astro.princeton.edu> writes:
> I'm attaching a patch that implements two classes, GdbOptionParser and
> GdbArgumentParser, which are built around python's standard optparse
> and argparse but play well with gdb (e.g. don't call exit if you make
> a typo or ask for help!). The code imports with python >= 2.3, but
> only provides the argparse-based parser if you actually have argparse
> in your path (python == 2.7?).
>
> The patch:
> Implements the classes
> Adds docs
> Adds test cases
>
> What else do you need to get this into the source tree? I'm not sure
> how to deal with copyright assignment.
The right place to submit patches is not this list. You should rather
use gdb-patches@sourceware.org. About copyright assignment, I can send
you the form if you want.
Also, you need to write a ChangeLog entry for this. And I'd suggest
cleaning the patch a bit, because it contains some useless lines like:
> ? .deps
> cvs diff: Diffing .
> Index: utils.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/utils.c,v
> retrieving revision 1.265
> diff -a -c -w -r1.265 utils.c
> *** utils.c 4 Nov 2011 16:45:12 -0000 1.265
> --- utils.c 11 Nov 2011 19:20:09 -0000
> ***************
> *** 729,736 ****
> --- 729,740 ----
> struct timeval now_wall_time, delta_wall_time;
>
> gettimeofday (&now_wall_time, NULL);
> + #if 0 /* no timeval_sub */
> timeval_sub (&delta_wall_time,
> &now_wall_time, &start_stats->start_wall_time);
> + #else
> + delta_wall_time.tv_sec = delta_wall_time.tv_usec = 0; /* HACK */
> + #endif
If this is a hack, then it should be fixed before submitting the patch.
Have you run a regression test against this patch? It is a common
practice, and should be always done.
Otherwise, thanks for the work.