Re: header file guards conflict

[Akim Demaille]

Le 21 mai 2012 à 11:34, Akim Demaille a écrit :

> 
> Le 16 mai 2012 à 16:51, Wei Song a écrit :
> 
>> Hi,
> 
> Hi!
> 
>> Just have used Bison for several months.
>> 
>> I have two bison parsers in one project and for some reasons the header 
>> files of both parsers are included in one cpp code.
>> Different namespace names are used, therefore, these two parsers do not 
>> conflict.
>> However, there is an unexpected problem.
>> The header guard in location.hh is BISON_LOCATION_HH, the same in both 
>> location.hh files (not only this file).
>> As result, I need to do something like the following in my code:
>> 
>> #include "parser1.hh"
>> 
>> // undefine all the conflicted header guards
>> #undef PARSER_HEADER_H
>> #undef BISON_LOCATION_HH
>> #undef BISON_POSITION_HH
>> 
>> #include "parser2.hh"
>> 
>> Is there a better way to do it?
> 
> This is indeed a problem.  I'm sure what the best way to
> address this is.  In addition, in some cases, creating the
> files location.hh, stack.hh etc. is more troublesome than
> useful.
> 
> Also, some people would like to be able to rename the location.hh
> file.
> 
> Currently we use BISON_LOCATION_HH (it is open-coded).  One
> first idea would be to use the output file name, so if
> for instance you passed "-o lang1/parser.cc", the header would
> be BISON_LANG1_LOCATION_HH.  Would that suffice in your case?
> Maybe BISON_ is not needed actually.
> 
> Maybe we should also include the given name-prefix?  So
> this would typically be YY_LANG1_LOCATION_HH.
> 
> Don't you have the exact same problem with your parser
> header file?  Currently it is PARSER_HEADER_H…  Using
> name-prefix + full output name (with directory) that
> would be YY_LANG1_PARSER_HH.

I have started something in that spirit.  There is one
issue: the file name can be ugly (typically in a VPATH
build there can be plenty of "../"), so the CPP guard
is not nice looking either.  For instance, in _my_ build
of bison (with builddir=_build/debug7), I have
examples/calc++/location.hh that looks like this:

> /**
>  ** \file ../../../../examples/calc++/location.hh
>  ** Define the yy::location class.
>  */
> 
> #ifndef YY_____________EXAMPLES_CALC___LOCATION_HH
> # define YY_____________EXAMPLES_CALC___LOCATION_HH
> 
> # include <iostream>
> # include <string>
> # include "position.hh"
> 
> 
> namespace yy {
> 
> /* Line 168 of location.cc  */
> #line 50 "../../../../examples/calc++/location.hh"
> 
>   /// Abstract a location.
>   class location

But really, I think handling srcdir vs. builddir is a
different issue that I don't wish to address now.

I still cannot release 2.5.1 because I have issues with
the generated ChangeLog that need to be addressed first.
So I am tempted to include this into 2.5.1, even though
it is quite a change.  I'd be happy to have opinion on this.

There are four related patches:

3dcbe90 lalr1.cc: extract stack.hh.
  To make merging easier in master.
d5c5e39 lalr1.cc: improve Doxygen documentation.
  To include the prefix part in the \file directive.
e7db5ac skeletons: remove support for unused directive.
  Something that should never have been included.
84e027a c++: compute the header guards.
  Really compute the CPP guards.

These patches do not add CPP guards to the C headers,
parser.h, generated by glr.c and yacc.c.  Maybe we should?

The patches will follow.  In "next" ATM.