Re: header file guards conflict

[Hans Aberg]

On 21 May 2012, at 18:34, Akim Demaille wrote:

> Le 21 mai 2012 à 18:27, Hans Aberg a écrit :
> 
>> On 21 May 2012, at 18:17, Akim Demaille wrote:
>> 
>>> Le 21 mai 2012 à 17:55, Hans Aberg a écrit :
>>> 
>>>> Is there any reason to not put all stuff that is public in the parser 
>>>> header? This would eliminate the need for any additional header files.
>>> 
>>> That's the plan for those that need not be public.
>>> location.hh is different: you may use it for your
>>> ASTs if you wish.  I, for one, do that.
>> 
>> Hm, I meant: put all stuff that the user might access in the parser header, 
>> and the other stuff in the parser source. The names belonging to different 
>> parsers won't collide if given different namespaces.
> 
> That's too much dependencies to inject.  An AST does
> not need details about the parser, especially since these
> details may change when you touch the grammar.  Even adding
> empty lines in the grammar can change the header.  It would
> be disastrous to force a compilation of an AST hierarchy
> because of an eager #include where location.hh would
> suffice.
> 
> Besides, when possible, it is certainly desirable to keep
> a single version of the code, to avoid bloating the binary.
> Weaker argument in the present case, I agree.

So there should be more than one header. In order to separate them for 
different parsers residing the same directory, the simplest default seems to 
mark all filenames with the name of the parser.

Hans