Hi Adam, > Le 23 sept. 2020 à 22:25, Adam Novak <ano...@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!
