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

[Adam Novak]

> Don't commit the generated files, just ship them.

How would you recommend I "ship" these generated files, along with
today's bugfix commits, to the rest of my research group, without
committing them? And how should they be delivered to CI infrastructure
to test new commits to the project, if they aren't in the repo?

Overall, it sounds like the Bison project has little interest in
supporting build flows that don't do things the GNU way, with real
tarball releases from designated, competent maintainers. That's a fine
position to take, especially if you think that model is the Right Way
to run a project. However, it invites a fork designed to generate
parsers at build time (or just build straight from .y to .o),
especially if developers on different distros are already installing
Bison from source anyway to collaborate on the same .y files.

Git-centric, high-dependency development styles are probably not going
to go away just because Bison fit them well.



On 9/23/20, Akim Demaille <akim@lrde.epita.fr> wrote:
>
>
>> Le 21 sept. 2020 à 10:15, Kaz Kylheku <kaz@kylheku.com> a écrit :
>>
>> On 2020-09-19 02:07, Akim Demaille wrote: no.
>>
>>> Fighting your tools is certainly one way to have endless problems with
>>> them.
>>
>> I'm not sure how I could have predicted that y.tab.h will suddenly
>> start declaring yyparse.
>
> The same complain as five years ago?  Seriously?
>
> https://lists.gnu.org/archive/html/bug-bison/2015-08/msg00006.html
>
> Could we just move forward?
>
>
>> Now I understand though that the way we avoid fighting with Bison is:
>>
>> 1. Never use a distro packaged Bison. Commit to a particular version.
>>   Build that Bison version yourself, from its official tarball.
>
> Of course, that's an overstatement.  Most grammar files don't have
> such problems.
>
>
>> 2. Have a "maintainer mode" in your program's configuration. The program
>>   only runs Bison when configured in maintainer mode. In non-maintainer
>>   mode, it builds the generated files.
>
> You may call this a maintainer mode if you want (Bison for instance
> does not have one), but yes, *shipping* the generated files buys
> you freedom, and relieves your users from your requirements.
> Don't commit the generated files, just ship them.
>
>
>> 3. When updating to a different Bison version, just fix anything that
>>   breaks and move on. Fix it using what is evidently the best practice
>>   under that version of Bison, or else find another version that
>>   doesn't require the fix or needs less of a fix. (This is where
>>   we avoid fighting.)
>
> You are currently mostly concerned with "mandated" updates to
> your files (i.e., adjustments required by newer versions) because
> that's currently the problem at hand you are striving to address.
>
> But I claim that once you made that jump to using %code etc. (which,
> I agree, is painful for you, but brings you from a distant past
> to only twelve years ago) then
>
> (i) you will see that we pay attention to backward compatibility,
>   so you should not have this kind of problems soon
>   (there are still old things that I'm getting rid of, e.g., YYPRINT,
>   so I'm not claiming it will never happen again, I'm just saying
>   that it's not as frequent as you depict it).
>
> (ii) you will be more likely evolve your grammar files to benefit
>   from new features.  _If_ you ship your generated files, then
>   you will be freer to use more recent features to simplify your
>   parser.  I'm not suggesting you should jump to the bleeding edge
>   release, but wait for say half a year so that the Bison release
>   is widespread enough for your casual contributors to have it
>   on their distros.  The end users, and the distros, will not
>   have any such issues, since your tarball is self contained and
>   independent of Bison being installed or not.
>
>
>> With this workflow, you never have any reason to engage in any
>> time-wasting interactions with the Bison project, like submitting test
>> cases or reporting issues, especially if all your requirements
>> are easily met by decade-and-a-half old versions of Bison.
>
> You loaded this paragraph with tons of irony, which is a pity,
> because you were making a lot of sense.  Shipping the generated
> parsers will also allow you to kiss bison bye bye, and play it safe
> by using byacc only.
>
> Please, do that.
>