Re: RFC: c++: provide control over the stack.hh file name

[Akim Demaille]

> Le 24 sept. 2018 à 22:50, Frank Heckenbach <address@hidden> a écrit :
> 
> Akim Demaille wrote:
> 
>> In the case of stack.hh, I think we don't care.  In fact, I expect
>> people to '%define api.stack.file none' to not generate this file.
> 
> BTW, couldn't this be the default, since you say it's not needed
> outside of the parser? Would it break anything?

Build systems expecting that stack.hh is generated will
probably break.

I have often contemplated the possibility to hook ourselves
to the required version of Bison (%require) to change the defaults.
For instance, %require "3.2" would change the default of
api.stack.file to ’none’.

I’m not sure whether it’s a smart or dumb idea.

>> But in the case of location.hh/position.hh, it might be important
>> to generate them in foo/ast while the parser is in foo/parse.
>> But then, what should the #include look like?  Maybe we cannot
>> just invent it, and should also introduce api.stack.include to
>> specify it.
>> 
>> Just thinking aloud.  But I'd be happy to not be alone doing so :)
> 
> Maybe just leave it up to the user to give the necessary "-I"
> options then?

In my case for instance, the location files become public, while
the generated parser remains in the implementation details.  And
two different directories hierarchies.  For the public hierarchy
I use a single -I, pointing to the root of the public header
hierarchy, and all my #includes are with angle brackets, qualified.
For instance #include <vcsn/misc/location.hh>.

So there’s no direct relation between the path in which the file
should be generated, and the path for the #include.  Currently
I use a wrapper to address this.

        $(AM_V_at)$(BISONXX) $(BISONXXFLAGS)    \
          --location-dir=$(srcdir)/vcsn/misc    \
          --location-prefix=vcsn/misc --        \
          $< $(srcdir)/%D%/parse.cc             \
          $(AM_BISONFLAGS) $(BISONFLAGS)

I’d be happier without this wrapper.


>> PS/  Not sure api.* is the appropriate prefix for file names.
> 
> Maybe fhs.*? But I admit I haven't spent much thought on the symbol
> hierarchy in general.

fhs looks a bit cryptic :)