Remove HAVE_* for always available extensions #3912

carusogabriel · 2019-03-03T19:22:30Z

As the Reflection extension now builds by default and can't be disabled, these isn't necessary.

petk · 2019-03-03T19:35:14Z

Yes, I think having these constants defined doesn't make sense anymore. Same can be probably done for date, hash, spl. It maybe is weird to define something that is always there but I'm not sure how this affects writing extensions where for example something is checking if reflection is present and suddenly that won't be defined anymore. I'm not sure what is more logical in this case, so if you think that this should be dropped, I think it's ok and we add it also to the UPGRADING.INTERNALS...

KalleZ · 2019-03-03T19:37:21Z

Like @petk said, it is fine to do for all the always enabled extensions if there is any similar constants

carusogabriel · 2019-03-03T19:56:01Z

SPL, Reflection, Standard, Date, Hash, PCRE, any other extension that is built by default and can't be disabled?

petk · 2019-03-03T20:00:03Z

I think these are it, yes. In reality the filter and readline are also a bit difficult to disable and build as shared but that's nothing related to this issue...

carusogabriel · 2019-03-03T20:04:22Z

Removing the HAVE_SPL might be complicated. Take a look at this, for example, some checks with it were introduced at 569d164. How should they become?

petk · 2019-03-03T20:14:25Z

I'm not sure if this was in the past defined as BC break since it only concerns extension developers... For the ZIP extension notice also the if else check where it will apply for PHP 5.6 for example. For PHP < 7 versions SPL was maybe missing. So on PHP 7.4 it won't even reach that part. But yes these might be in the extensions out there. We can also add that in the UPGRADING.INTERNALS so the extension authors can upgrade them properly when adjusting for PHP-7.4+...

krakjoe · 2019-03-03T20:41:16Z

It seems reasonable to remove them to me. There are extensions out there targeting both PHP 5 and 7 in the same source, but it's not too much effort to check the version, and they'll be likely making changes for 7.4 anyway. Adding info to upgrading seems sufficient then.

…

On Sun, 3 Mar 2019 at 21:14, Peter Kokot ***@***.***> wrote: I'm not sure if this was in the past defined as BC break since it only concerns extension developers... For the ZIP extension notice also the if else check where it will apply for PHP 5.6 for example. For PHP < 7 versions SPL was maybe missing. So on PHP 7.4 it won't even reach that part. But yes these might be in the extensions out there. We can also add that in the UPGRADING.INTERNALS so the extension authors can upgrade them properly when adjusting for PHP-7.4+... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3912 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACIe6rFyK6dVKzsLEESj_TmNfUsGrdH9ks5vTC0rgaJpZM4bbLlN> .

KalleZ · 2019-03-03T21:14:01Z

Removing the HAVE_SPL might be complicated. Take a look at this, for example, some checks with it were introduced at 569d164. How should they become?

Since PHP 5.3.0 the SPL extension has always been available, I think it is fair to assume that code that does cross compilation over multiple PHP versions do not support so far back so I cannot see it being an issue and developers can therefore check for such.

Edit: Optionally you can provide a patch for the ZIP extension to use such a check, which I think @remicollet would gladly accept

carusogabriel · 2019-03-05T15:45:28Z

ext/pcre/config.w32

 ADD_SOURCES("ext/pcre/pcre2lib", "pcre2_auto_possess.c pcre2_chartables.c pcre2_compile.c pcre2_config.c pcre2_context.c pcre2_dfa_match.c pcre2_error.c pcre2_jit_compile.c pcre2_maketables.c pcre2_match.c pcre2_match_data.c pcre2_newline.c pcre2_ord2utf.c pcre2_pattern_info.c pcre2_serialize.c pcre2_string_utils.c pcre2_study.c pcre2_substitute.c  pcre2_substring.c pcre2_tables.c pcre2_ucd.c pcre2_valid_utf.c pcre2_xclass.c pcre2_find_bracket.c pcre2_convert.c pcre2_extuni.c", "pcre");
 ADD_DEF_FILE("ext\\pcre\\php_pcre.def");

 AC_DEFINE('HAVE_BUNDLED_PCRE', 1, 'Using bundled PCRE library');


Not sure if we can drop this one as well

nikic · 2019-03-05T16:15:38Z

ext/mbstring/mbstring.c

 # include <oniguruma.h>
 # undef UChar
-#elif HAVE_PCRE || HAVE_BUNDLED_PCRE
+#elif HAVE_BUNDLED_PCRE


This should be removed entirely instead. if HAVE_PCRE || HAVE_BUNDLED_PCRE => if 1 => always true.

nikic · 2019-03-05T16:17:17Z

ext/session/php_session.h

 #include "ext/standard/php_var.h"

-#if defined(HAVE_HASH_EXT) && !defined(COMPILE_DL_HASH)
+#if !defined(COMPILE_DL_HASH)


This if should also be completely dropped.

nikic · 2019-03-05T16:18:03Z

I'd recommend keeping HAVE_HASH_EXT because it is only recently required and HAVE_PCRE, because I think there's quite a lot of ext code (unnecessarily) checking for HAVE_PCRE || HAVE_BUNDLED_PCRE. (Any checks can of course be dropped.)

KalleZ · 2019-03-05T16:33:10Z

@nikic I believe PCRE has been a special extension since 5.3 as well, so I think it should be removed instead, even if their checks is unnecessary. We should label it as such in the UPGRADING.INTERNALS.

For ext/hash, I think we should keep the check for now, at least until 8.0.

Alternatively we can keep defines until 8.0 to ease 7.x extensions (my personal preference).

krakjoe · 2019-03-15T07:10:19Z

Alternatively we can keep defines until 8.0 to ease 7.x extensions (my personal preference).

@KalleZ since this won't be merged lower than 7.4, and 7.4 is going to be the last in 7 series, I would say it's not a really big deal to just remove defines that can be removed now, excluding hash, hash one should be removed in master to ease the 8 upgrade (likely already ifdefs for 80000)

KalleZ · 2019-03-15T07:11:17Z

@krakjoe I’m fine with that approach

carusogabriel · 2019-03-16T09:13:45Z

Looks like removing some of these extensions isn't trivial: https://ci.appveyor.com/project/php/php-src/builds/23120735/job/rpqc5sc0ikuqe00s#L624.

I'll only remove from SPL, Reflection, and Date for now.

KalleZ · 2019-03-19T02:03:24Z

@carusogabriel I wrote this quick patch for PCRE (for current master), you can adapt into this PR: https://gist.github.com/KalleZ/08feb65ca07e8d9ffd4babd90f628ef2

Notes:

This effectively removes HAVE_PCRE, HAVE_BUNDLED_PCRE & COMPILE_DL_PCRE
The changes to ext/filter/config.m4 is NOT tested. It should keep the current behavior of disallowing shared builds of ext/filter (why I have no idea when we don't disallow this behavior on Windows, but that is a debate for another topic)
~~As a side-effect of the changes to ext/filter/config.m4, it removes the legacy PECL builds, it may need some further looking into at C level~~

Edit: As of this edit, I updated the patch to omit the changes to ext/filter/config.m4 as I will commit a separate patch for this myself for 8.0. If you use the above patch, then remember to update ext/filter/config.m4 carefully

carusogabriel · 2019-03-19T20:03:03Z

@KalleZ Thanks for the patch. I'll update this PR with that, so we can deliver it 🚢

KalleZ · 2019-03-20T18:12:13Z

@carusogabriel I synced ext/filter/config.m4 in PHP-7.4 and will take care of HAVE_HASH in master shortly

Edit: Removed HAVE_HASH_EXT and COMPILE_DL_HASH in master

The PHP SPL extension is always available in PHP since somewhere around PHP 5.3. The HAVE_SPL constant has been removed upstream via php/php-src#3912

sodabrew · 2019-06-27T14:01:25Z

This is awful and you are breaking extensions by doing this, causing some (like memcached as noted by the pull request above) to fall back to old / disabled behavior.

Even if I accept the PR to the memcached extension promptly and cut a release right away, if someone compiles an older extension against PHP 7.4 it would behave badly in a new way. (Granted there is a version check in the peck xml, I don’t recall how strongly enforced this is if a user forces the installation or worse, if an automated installer wrapper script forces it.)

So here’s what I propose: redefine these HAVE_* constants in a way that generates a compiler warning or even an error. Use this to give notice that PHP 8 will remove the constants.

petk · 2019-06-27T19:57:27Z

I was just listening to @derickr and @krakjoe (https://derickrethans.nl/phpinternalsnews-16.html) and basically there is also mentioned that ABI can be broken from PHP 7.3 to 7.4 in ways of BC. Otherwise, I understand the frustration. Sort of...

I'm not sure entirely how would that work with the error happening on the compilation step... To me it sounds a bit bloated but that's how this really should be solved, yes. Breaking API on the other hand is the most awful thing. More than ABI. Semantic versioning in ideal world would be essential to follow. Case is that C ecosystem is not ideal world. Far away from it. But PHP world should be approximation of the ideal world. Or at least we should try in such direction.

I'm scanning the PHP extensions periodically, no worries. It's not that bad situation with these HAVE_* symbols as one might think. There were bigger ABI BC breaks done in PHP 7.4 I think.

Currently all extensions (at least the alive ones) have received the pull requests to fix this HAVE_SPL symbol.

The memcached extension in particular has from my current state, all fixed except the HAVE_SPL.

Hope we can make it... Regards.

sodabrew · 2019-07-01T12:18:16Z

I had something like these in mind:

#define HAVE_SPL #error "The HAVE_SPL macro has been removed; your code no longer needs non-SPL fallback since PHP 5.3, so we promise that fallback is bit-rotted anyways."

#define HAVE_SPL _Pragma ("GCC error \"The HAVE_SPL macro has been removed; your code no longer needs non-SPL fallback since PHP 5.3, so we promise that fallback is bit-rotted anyways.\"")

But both of these just return true for #ifdef HAVE_SPL. So much for that idea.

petk · 2019-07-01T18:34:29Z

@sodabrew very nice. My C-foo is not there yet to suggest a way here to produce such errors when compiling. There are even multiple compilers then used... Otherwise this would be really neat trick. Depends also if there is some impact on performance of the overall code...

carusogabriel added the Category: Build System label Mar 3, 2019

carusogabriel requested a review from petk March 3, 2019 19:22

KalleZ self-requested a review March 3, 2019 19:37

KalleZ approved these changes Mar 3, 2019

View reviewed changes

petk approved these changes Mar 4, 2019

View reviewed changes

carusogabriel changed the base branch from master to PHP-7.4 March 5, 2019 15:32

carusogabriel commented Mar 5, 2019

View reviewed changes

carusogabriel changed the title ~~Remove HAVE_RELFECTION~~ Remove HAVE_* for always available extensions Mar 5, 2019

nikic reviewed Mar 5, 2019

View reviewed changes

Remove HAVE_* for always available extensions

656db96

php-pulls merged commit 656db96 into php:PHP-7.4 Apr 14, 2019

carusogabriel deleted the chore/remove-have-reflection branch April 14, 2019 14:52

petk mentioned this pull request Jun 26, 2019

Remove unused HAVE_DATE and HAVE_SPL symbols #4311

Closed

petk added a commit to petk/php-memcached that referenced this pull request Jun 26, 2019

Remove usage of HAVE_SPL

7493b75

The PHP SPL extension is always available in PHP since somewhere around PHP 5.3. The HAVE_SPL constant has been removed upstream via php/php-src#3912

petk mentioned this pull request Jun 26, 2019

Remove usage of HAVE_SPL php-memcached-dev/php-memcached#441

Closed

petk mentioned this pull request Jul 26, 2019

Sync extension enablements symbols #4452

Closed

13 tasks

Remove HAVE_* for always available extensions #3912

Remove HAVE_* for always available extensions #3912

Uh oh!

Conversation

carusogabriel commented Mar 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petk commented Mar 3, 2019

Uh oh!

KalleZ commented Mar 3, 2019

Uh oh!

carusogabriel commented Mar 3, 2019

Uh oh!

petk commented Mar 3, 2019

Uh oh!

carusogabriel commented Mar 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petk commented Mar 3, 2019

Uh oh!

krakjoe commented Mar 3, 2019 via email

Uh oh!

KalleZ commented Mar 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

carusogabriel Mar 5, 2019

Choose a reason for hiding this comment

Uh oh!

nikic Mar 5, 2019

Choose a reason for hiding this comment

Uh oh!

nikic Mar 5, 2019

Choose a reason for hiding this comment

Uh oh!

nikic commented Mar 5, 2019

Uh oh!

KalleZ commented Mar 5, 2019

Uh oh!

krakjoe commented Mar 15, 2019

Uh oh!

KalleZ commented Mar 15, 2019

Uh oh!

carusogabriel commented Mar 16, 2019

Uh oh!

KalleZ commented Mar 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

carusogabriel commented Mar 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KalleZ commented Mar 20, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sodabrew commented Jun 27, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petk commented Jun 27, 2019

Uh oh!

sodabrew commented Jul 1, 2019

Uh oh!

petk commented Jul 1, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

carusogabriel commented Mar 3, 2019 •

edited

Loading

carusogabriel commented Mar 3, 2019 •

edited

Loading

KalleZ commented Mar 3, 2019 •

edited

Loading

KalleZ commented Mar 19, 2019 •

edited

Loading

carusogabriel commented Mar 19, 2019 •

edited

Loading

KalleZ commented Mar 20, 2019 •

edited

Loading

sodabrew commented Jun 27, 2019 •

edited

Loading