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

[Akim Demaille]

Hi Adam,

> Le 23 sept. 2020 à 22:25, Adam Novak <anovak@soe.ucsc.edu> a écrit :
> 
>> 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?

There are several options.  One is to install on your CI your
dependencies, i.e., a version of Bison that matches your requirements.
The other one, if your CI supports pipelines, is to have one early
stage that wraps the tarball, and the next ones start from the
tarball.

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

This is not what I meant.  In the case of Kaz, who is looking for
backward compatibility with very old versions of Bison, and very
old versions of his projects, that's the way to go.

Yet, most users have setups that work very well without all this.


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

Most users simply don't have such issues.  The only cases where
this is a problem is when users play tricks on the generated files,
because, of course, they have a much higher dependences on the
exact spelling.  Features have been introduced to address the needs
that forced people to hack the generated files and avoid these
issues.

I'm sorry I forgot the thread was actually about a problem you
reported.  So let's go back to exactly that: you have a problem to
solve.  Give me some time to look at what you are doing in your
package, and I'll come back with proposals.

Cheers!