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

[Frank Heckenbach]

Hi Akim!

> 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 see. (Didn't think of it since I don't usually put generated files
in my tarballs or, for that matter, deb-src packages. Of all the
build dependencies they need, Bison is one of the easiest to
install, 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.

Agreed.

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

For files that depend on the location type and not the parser header
(which would be none for me, but if there are some in your code,
that's an advantage, indeed).

So it seems like you'll need to keep the 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.
> 
> I fully agree with this!
> https://stackoverflow.com/a/17060587/1353549

I didn't know this post, but we definitely agree about not using
relative paths.

Apart from that, I don't mind users of my libraries having to use
one or more "-I" options since I use pkg-config, so this will
usually happen automatically.

Regards,
Frank