[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/3] skeletons: use header guards.

From: Bruce Korb
Subject: Re: [PATCH 1/3] skeletons: use header guards.
Date: Fri, 15 Jun 2012 09:20:45 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

Hi Akim,

For my part, when this all happens is unimportant.
Nowadays, I'm writing stuff that should build and run anywhere,
let alone requiring recent GNU tools.  So if you have delays,
it won't bother me at all.

On 06/15/12 07:22, Akim Demaille wrote:
Sorry I failed to send the introduction message (and actually lost

There are two shortcomings.

(i) When using yacc.c, parser.c now includes parser.h instead of
duplicating its content.  glr.c and already work like this.
Yet it means that parser.c must know where parser.h is in order to
#include it.  Currently all the implementation files (with yacc.c,
glr.c,, include the basename of header file, so -I
should suffice to find it.  But instead of basename, I am
contemplating the use of code from coreutils to compute relative
paths, to handle cases such as --output=a/b/c/my-parser.c
--defines=a/d/my-header.h (but, as I reported elsewhere, I am stunned
by the impact this gnulib modules would have, comments most welcome:

Too complicated.  The output parser should #include the header
using just the base name surrounded by double quotes.  If the
header gets redirected to another directory, it becomes the
responsibility of the developer to specify the correct -I option.
All that relative directory path stuff is very cute, but of little
practical value and adds too many inter-dependencies for what I
see as a marginal gain.

One very useful addition will be adapting ylwrap.
As it stands now, the .h file is always thrown away.  Ick.
Consequently, I have to auto-edit the ylwrap script
to preserve the header, and that is quite a nuisance.
I'm sure that that is a autoconf/automake issue tho.

(ii) YYSTYPE and YYLTYPE are not renamed.  As already discussed, this
will be covered by some new %define api.prefix "foo" which will
deprecate %name-prefix.

That will be very nice.  Thanks!

Cheers - Bruce

reply via email to

[Prev in Thread] Current Thread [Next in Thread]