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

[Akim Demaille]

Hi Frank!

> Le 27 sept. 2018 à 21:20, Frank Heckenbach <address@hidden> a écrit :
> 
> Akim Demaille wrote:
> 
>>> 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 see. Though since no user code (should) depend on it, why would
> the Makefile? But I admit there are strange Makefiles (or other
> build systems) out there, so one never knows …

For a start, you list the file you want to ship in the tarball.
If we no longer generate this file, it might break, or we might
leave the old one in place.  Which is harmless, but not very
sane.

>> 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.
> 
> Generally, I'm skeptical of such coupling. But if it allows us to
> get rid of it in the long run, it might be worth it. But will it
> allow us to, or will we have to support the old way for decades
> anyway?

I was not trying to get rid of this file in the long run, but
you are right, it might be a better option.  So instead of
generating a meaningful stack.hh, we could just as well leave
the definition of stack in parser.hh, and generate a stack.hh
which is just a stub, mentioning in a comment how to not generate
it.

That’s because I think nobody is actually using stack.hh.


> BTW, I just noticed a naming conflict (yeah, aren't name hierarchies
> great to prevent this ;). In another change I made (unrelated to my
> main changes, but in order to allow using another container such as
> deque, as suggested by Hans Åberg) I used:
> 
>  %define api.stack.include deque
>  %define api.stack.container {std::deque}
> 
> Of course, this can be changed (if you want to include this patch at
> all — I don't care either way).

Do you think it’s useful?  We used to use deques in the generated
parser, but in 
http://lists.gnu.org/archive/html/bison-patches/2013-01/msg00010.html
we moved to vector because I don’t see what it buys us.  Sure, it
saves us from occasional copies when the vector grows, but that’s
all.  At the cost of more indirections.


>> 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.
> 
> To me another "-I" option would still seem easier than this
> monstrosity. ;)

I agree, it’s easier.  But this is a library, and I don’t want my
users to have to add more -I when they use it.  So I really want
location.hh to be where it needs to be.

There’s another advantage with this wrapper: the file is not
updated if the content did not change, which is almost always
for location.hh and the others.  This saves me from useless
compilations.


> Anyway, I don't see how Bison can produce the correct relative path
> in all cases. Another nice one to consider is if some subdirectory
> is a symlink, so if you have foo/bar and foo/baz and you're in
> foo/bar, ../baz will not necessary land in foo/baz. I once worked in
> a project that had this, and the rule I set myself was to never use
> .. in paths, instead pass down absolute paths where necessary.

I fully agree with this!
https://stackoverflow.com/a/17060587/1353549


>>>> 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 :)
> 
> Not to me. :)
> 
> Of course, it means "File System Hierarchy" and it's an acronym that
> has to be learned just like API. But I don't really mind. I (and
> I suspect most users) will just copy the name from the documentation
> once it’s finalized.

Sure.