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

[Michael Geng]

On Mon, Jun 16, 2008 at 09:43:37PM +0200, Jim Meyering wrote:
> address@hidden (Michael Geng) wrote:
> ...
> > I think emitting into a .h file would be a good solution. But wouldn't
> > it then be better to directly add a genparse file (e.g. ls.gp) instead of
> > extracting it from ls.c? ls.c would no longer have to be modified then.
> 
> The disadvantage is that there would then be bits of code in ls.gp
> that depends on declarations in ls.c.  I.e., "static", file-scoped
> variables in ls.c would now also appear in ls.gp.  That is too distant
> for my taste.  That would also add ~100 more version-controlled *.gp
> "source" files.

I uploaded a new patch to 
http://genparse.sourceforge.net/coreutils/genparse-07-18-2008.patch.
With that patch the distribution tarball will include ls.in.c which 
contains the genparse input file at the bottom. Make will automatically
extract it and move the generated parser to ls-gp.h which will also be
part of the distribution tarball. ls.c will not be distributed but
generating it from ls.in.c only requires sed, not genparse. So there is
no code duplication in the distribution. Conceptionally genparse is not a 
build time requirement but actually it still is because the configure-script
doesn't yet check if genparse is available.

About translations: I suggest that gettext is applied on the generated parser
(ls-gp.h), not on the genparse input at the bottom of ls.in.c. On the rest, 
shall gettext be applied on ls.c or ls.in.c? The difference between ls.in.c 
and ls.c is only genparse input file which is attached at the end of ls.c as a 
comment. ls.c is a generated file now. For this reason make distcheck fails
with this patch (because it doesn't find ls.c during the translation checks) 
although make check succeeds.

You will need genparse v0.7.7 in order to process the parser in this patch.
It is available from http://genparse.sourceforge.net/ as usual.

How about this concept?

Michael