Re: Command line parsing of ls with genparse: inline code

[Jim Meyering]

address@hidden (Michael Geng) wrote:
> when I posted a patch around Christmas which showed how genparse
> could generate the parser code for the ping command of the inetutils
> Alfred Szmidt replied that in that example there are 2 loops (see
> http://lists.gnu.org/archive/html/bug-inetutils/2007-12/msg00007.html):
>
> 1. The switch statement which sets the arg_t struct with the
>    results of getopt_long in ping-clp.c
>
> 2. A list of if-clauses which sets the already existing variables
>    in ping.c from the arg_t struct
>
> I now released a new version of genparse (0.7.6) which allows to put
> the generated parser code inline of existing code, replacing almost
> exactly the existing C code. This version has 2 extensions:
>
> 1. A __CODE__(statements) directive which allows to let the user define
>    the code which is executed in the switch statement which evaluates
>    the results of getopt_long.
>
> 2. A global directive #no_struct. If specified in the genparse file
>    then no arg_t struct struct is generated.
>
> I uploaded a patch which shows how this works for the ls command of
> the coreutils. It transforms ls.c.in which has the genparse file inline
> into ls.c which has almost exactly the same command line parser code
> inline as the present version of ls.c. The patch is targeted to today's
> git version of the coreutils. I verified that it passes make distcheck.
>
> Please use the following links:
>
> patch:   
> http://genparse.sourceforge.net/coreutils/genparse-ls-inline-git-01-19-2008.patch
> ls.c.in: http://genparse.sourceforge.net/coreutils/ls.c.in (included in the 
> patch)
> ls.c     http://genparse.sourceforge.net/coreutils/ls.c    (included in the 
> patch)

Hi Michael,

If you're still interested (and willing to work! ;-)
I think we're getting close.  I hope you understand the delay.
We're contemplating a massive change, and I want to be sure
I don't end up regretting it.

Now that coreutils-6.12 is out, once two remaining points
are addressed, then I think we'll finally be ready to switch
a few trial programs.

Please add #line directives in the emitted C code, so that
debuggers know the source file/line-numbers.

I'd really like to avoid having to move the primary source
for 100+ C files from .c to .c.in files (or .in.c).
I'm not sure how best to address that.  Here are some thoughts:

We might arrange for automake to emit an augmented .c-to-.o rule
that invokes genparse along the way (this is where #line directives
become essential -- the postprocessed intermediate .c file may not even
exist after it's compiled.  Note however that that would add genparse
as a *build-time* requirement, so isn't really an option.  The usual
approach to solving this problem is to distribute both primary sources
and generated sources (e.g., yacc and lex sources ship with generated
.c files), but that would bloat the distribution tarballs.

One possibility would be to emit into a .h file the static
definitions for functions like Cmdline.  Then there would be
far less duplication.

Jim