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

[Akim Demaille]

Le 15 juin 2012 à 18:20, Bruce Korb a écrit :

> Hi Akim,

Hi Bruce,

> On 06/15/12 07:22, Akim Demaille wrote:
>> Sorry I failed to send the introduction message (and actually lost
>> it).
>> 
>> There are two shortcomings.
>> 
>> (i) When using yacc.c, parser.c now includes parser.h instead of
>> duplicating its content.  glr.c and lalr1.cc 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, lalr1.cc, glr.cc) 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:
>> http://lists.gnu.org/archive/html/bison-patches/2012-06/msg00023.html).
> 
> 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.

Actually, IIRC, the bug report that led to the use of basename
would have been handled properly with relative.  Personally,
I am unhappy that basename is used.  In several projects I work
on, headers form a hierarchy, so I really want my
--defines=parse/parser.hh to end in a header installed in
parse/, and #included this way.

Yet I agree that this cannot suffice for everybody.  So we
should probably split this in two: --defines provides the place
where the file will be created, and some other mechanism should
provide the name under which it is #included.  So I could happily
have --defines=$(top_srcdir)/include/vcsn/parse/parser.hh for instance,
and have #include "vcsn/parse/parser.hh" in the implementation
file.

Some people have expressed the desire to be able to use a single
location.hh header instead of several.  A means to specify the
names of the files to include could also help here (though I have
to think more about it).

Then the question remains on what the default should be: basename
or relative.

> 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.

Recent versions of Automake have addressed a number of issues
on this regards, so you should give them a try, and make
a bug report if you still have a problem.  I never had the
problem you describe.

>> (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!

I started to work on this.  It's in the api.prefix branch on the
master repository.

IMHO, this should be named 2.6, not 2.5.1.