-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Bump minimum Autoconf requirement for phpize from 2.59 to 2.64 #3562
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This patch syncs the minimum version used for the phpize.m4 script as is current requirement for the rest of the php code base and the main configure.ac. At the time of this writing Autoconf 2.63 is still the version on Centos 6, however by the PHP next release current systems out there should all have pretty much updated Autoconf versions to 2.64+ at least. Centos 7 already has Autoconf 2.69, for example. This provides more options to update and get current with the *nix build system. Additionally, phpize also already provides AX_CHECK_COMPILE_FLAG Autoconf Archive m4 file that has Autoconf 2.64 minimum requirement.
Comment on behalf of petk at php.net: Labelling |
CentOS 6 have autconf 2.63 by default, but this is already broken, so already have to use autoconf268 for PHP >= 7.2, so +1 And IMHO, fine for 7.3 @cmb69 ? |
Ubuntu Trusty also has autoconf 2.69, so 2.68 seems to be fine for PHP 7.3. Any objections, @smalyshev? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, this is good to be merged.
It might also make complete sense and be without issues to bump the Autoconf minimal requirement to the "latest" 2.69 (for the master branch). I'm not aware of any system except the Centos 6 with 2.63 today that wouldn't have 2.69 already... For the PHP 7.3, yes it would be ok to bump it also to 2.64 or 2.68 (I'm not sure how is this compatible with the releasing rules and the feature freeze rule). However, in practice I believe this won't cause any issues because most users will use 2.69... So, sorry for confusion but what should we do again here? |
It seems to me that the autoconf requirements of the core and of phpize should match. I wouldn't push further, unless there's a particular need for stable branches. autoconf 2.68 should be fine for PHP-7.3 and master. |
Got it. Yes, versions definitely should match because the *.m4 files get copied to the
Thanks... |
|
This patch syncs and bumps the minimum required version of Autoconf for the `phpize.m4` script and the main `configure.ac` from previously mixed 2.64 and 2.59 to 2.68. At the time of this writing Autoconf 2.63 is still the version on Centos 6, however by the PHP 7.3 release current systems out there should all have pretty much updated Autoconf versions to 2.64+ at least. Centos 7 already has Autoconf 2.69, for example. This provides more options to update and get current with the *nix build system and also avoids broken builds in certain cases as pointed out in the relevant discussion [1]. Additionally, phpize also already provides the `AX_CHECK_COMPILE_FLAG` Autoconf Archive m4 file that has Autoconf 2.64 minimum requirement. Autoconf 2.68 was released in 2010, 8 years ago, relative to this patch. [1] #3562
Applied via 0b0d4b5 into PHP-7.3 and master branches. Thank you all for your help and participation... |
This patch syncs the minimum version used for the phpize.m4 script as is current requirement for the rest of the php code base and the main configure.ac.
At the time of this writing Autoconf 2.63 is still the version on Centos 6, however by the PHP next release current systems out there should all have pretty much updated Autoconf versions to 2.64+ at least. Centos 7 already has Autoconf 2.69, for example.
This provides more options to update and get current with the *nix build system.
Additionally, phpize also already provides AX_CHECK_COMPILE_FLAG Autoconf Archive m4 file that has Autoconf 2.64 minimum requirement.
I think we should be ready to bump this slightly delayed and a bit forgotten part also...