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

[Frank Heckenbach]

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 ...

> 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?

> >> 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.

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).

> >> 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.

To me another "-I" option would still seem easier than this
monstrosity. ;)

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.

> >> 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.

Regards,
Frank