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.
_______________________________________________
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
