On Tue, February 10, 2015 14:15, Jakub Zelenka wrote: > Hi Anatol, > > > On Tue, Feb 10, 2015 at 12:24 PM, Anatol Belski <anatol....@belski.net> > wrote: > >> >> It's actually so that there is a range of tool versions supported. That >> means any version within the range should be valid for use. If another >> range of versions is defined, so it's obviously to follow it. It's >> good to make thoughts about the new features, but that'll be probably >> require updating the guidelines and changing the valid versions range. >> > > First of all it's great that you are adding the the type and cross > platform fixes into json. I understand why you needed to regenerate the > file. Well, thank you for your work )
> As you say there is a supported range. The problem is that the range is > too high which is very limiting for adding new features at the moment. > What I > don't want to do is to force all users compile the new tool version from > source because distros are still outdated . There also is no need to > require the new version for the whole PHP if it's needed just for json > generation. > IMHO that's exactly what is going to happen - users willing to regenerate the parser will have to get eventually another re2c version if they don't have it. As for me - I've just compiled re2c 0.13.6 for windows. But in general - using different tools for different parts of the core were probably a mess. >>> >>> As I said in the PR. This change won't affect anyone who doesn't >>> change json scanner and parser which is 99% of all users that build >>> PHP. The 1% >>> is probably just me so it's not really complicated IMHO... >>> >>> I would also like to add all of this to the json README (it's very >>> outdated and I plan to update it anyway) and possibly other build doc >>> if we have any. >>> >> Yeah, so why don't just push file and have it done? ATM there might be >> some fixes needed, so regeneration required. Later on it's supposed to >> be a very rare case - just in case of bugs or new development. Btw also >> people who don't have a required re2c/bison/etc version for whatever >> reasons would still be able to compile, test or develop other parts. >> >> > That's not actually completely true on linux. At least not on my > platform. I can recreate this on my system when I do following: > > > 1. install a different version of re2c then the > one Zend/zend_language_scanner.c (e.g. 0.13.6) 2. git checkout master > 3. ./configure ... && make > 4. checkout PHP-5.6 > 5. checkout master > 6. make > 7. git status ( it shows Zend/zend_language_scanner.c as regenerated using > 0.13.6 ) > > > The fact that I checked out the 5.6 [4] (it doesn't have to be just 5.6 > but some other branch with more changes) and then back master [5] caused > regeneration zend_language_scanner.c in [6]. The point is that as soon as > you start changing branches often, it gets regenerated even if you don't > change it. And then you need to have the required version because > otherwise the build fails. > > I want to prevent that for json generated files. This would be especially > visible for bison where the version differs more between users compare > to re2c where the most users are on 0.13.5. That's exactly what the PR > (config.m4 changes) does. > > As the versions in the range are interchangeable, it gives much more flexibility. Right now, if you open some release tarball - it is possible you see files generated with different bison/re2c versions because it doesn't matter much. Maybe it'd be worth it to move one step after another, see what features can be implemented and how do they improve? Maybe they'll be so crucial to even make a special case that one can say - yeah, don't care about flexibility? Not that one would restrict something without having the bare reason in the hand. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
