Re: api.header.include and backward-compatible .y files

[Akim Demaille]

Hi Kaz!

> Le 23 août 2020 à 09:01, Kaz Kylheku <kaz@kylheku.com> a écrit :
> 
> That said, Bison did a bad thing here. You see, POSIX requires y.tab.c to
> duplicate y.tab.h. That's why the skeleton was doing it.

No, it is not.  It was this way because some part grew organically
in the past, and sometimes the code screams from refactoring.

> Here is the wording from POSIX about y.tab.c:
> 
>   "It also shall contain a copy of the #define statements in
>   the header file."

Hum.  I have indeed overlooked this part.  Thanks.

> Now if that is the case, there is no reason for y.tab.c to include
> y.tab.h, which has the interpretation that you can rename it to whatever
> you want!

Yes.  But of course that is very dubious.  One would never do that
for a hand-written file, so why do it with generated files?

So for greater compliance with POSIX, in Yacc mode, I will certainly
restore the previous behavior.  But I dislike it.

Let's face it: the POSIX spec for Yacc contains a lot of silly things.
For instance using #define for tokens is silly.  enums are the obvious
right choice.  The table "Internal Limits in yacc" is also a good
source of laugh.



> Bison's change to reference the header file via #include is actually
> a nonconformance which breaks programs that rename the header.

Which is silly.  How on Earth can you defend people who lie to tools???
That _is_ asking for troubles.  Just be honest and use "--output foo.c
--defines bar.h".


> I see this in a 3.0.4 generated file:
> 
>  /* In a future release of Bison, this section will be replaced
>     by #include "y.tab.h".  */
>  #ifndef YY_YY_Y_TAB_H_INCLUDED
> 
> I.e. "a future release of Bison will raise a middle finger to
> IEEE 1003.1 which requires the following section ...".

Well, that was certainly not meant this way :)  But indeed, in
Bison mode, Bison will raise _all_ its fingers and wave silly
specs bye bye.


> The way Bison is maintained, it is such a moving target, that
> the the best thing to do may be to insist on a particular version of
> Bison for building your program.

The best way remains the one that has always been promoted:
*ship* the generated files.


> And since downstream distros that
> pick up your project, as well as regular users, will certainly not
> have that version of Bison, what you have to do is include the
> generated Bison code in your project, checked into your Git repo,
> and redistributed along with your source.

Which is also not what I'm saying.  People seem to have lots
the difference between a git snapshot and a tarball.

> This way only someone who wants to be a contributor
> (specifically, a contributor who wants to modify your .y files)
> has to then get that required version of Bison to rebuild the
> parsers.

This is right.

Cheers!