On Tue, Jul 17, 2018 at 6:05 PM Nikita Popov <nikita....@gmail.com> wrote:
> I feel like we are all really in violent agreement that these files should > be dropped from git, and at this point I'm not even sure what the > discussion is about anymore. Let's wait until after PHP-7.3 branching in > two weeks and drop them at that point. > > Normalizing the version numbers seems unnecessary after they are dropped > -- at least Dmitry's original motivation for that was related exclusively > to the spurious diffs caused by different versions, which will no longer be > an issue. > While we all agree that the files should be dropped from git - there appears to be disagreement regarding what else we need to do in addition. In my opinion if that's the only action we'd take then I don't think we should do it and the status quo is actually better - as it would mean that it will no longer be possible to build our packages in platforms that don't have re2c available or typically installed. It needs to happen hand in hand with providing these files in the source packages, and also ensuring that whatever boxes one uses to create the packages - as well as developers who check out the source code directly from git - have an acceptable version of re2c. It may be that we can accept a wide range of re2c versions (although if there are substantial differences in code perhaps it's better to err on the side of caution). I'm not sure why we're not simply following exactly what we're doing with the parser. We have a list of acceptable bison versions. We check both in configure and makedist against that list, and refuse to generate the parser otherwise. We don't track the generated .c file in source control - but we do include it in distros to account for environments that don't typically have bison installed. Why not do exactly the same with the re2c scanner? Zeev
