Add installed php extensions to temporary created ini file

[rhabacker]

In php extensions configured with phpize, a temporarily generated
php.ini is used for testing, but currently contains no installed
PHP extensions, which is required by the mailparse extension,
for example.

Installed extensions must be added with their absolute path,
because the extension_dir parameter is already occupied.

See https://bugs.php.net/bug.php?id=77609&edit=2

[rhabacker]

The mentioned build failure seems not to be related to this patch - how to proceed ?

[carusogabriel]

@rhabacker Please, rebase with master, I believe we got some fixes for the Windows CI.

[nikic]

You can just ignore the failure. A change to the Linux build system is definitely not going to break the Windows build ;)

[beberlei]

I love this change, working around this problem myself right now with the tideways extension, where tests depend on a lot of other extensions to verify instrumentation works.

[rhabacker]

Anyone there who can merge this pull request ?

[petk]

So, this is happening when the mbstring is built as shared extension, right? Yes, the shared extensions have many quirks... /o\

This seems to work ok, except one minor thing, I think. When the path to the extension is set as absolute path in the original *.ini file (/etc/php/conf.d/mbstring.ini) file, for example, extension=/usr/local/php/lib/php/20180731/mbstring.so (a bit dummy and made up case), the extension dir adds too many to the exported tmp-php.ini file.

Yes, as for the regex part of (zend_)?extension(_debug)?(_ts)? it needs to be refactored. Basically, that is nothing deprecated nor something to exclude from the test ini file itself. At least not extension= parts...So probably the new correction is fine unless there is a need to somewhere load some of those special extensions such as zend or debug ones.

[rhabacker]

You suggest to remove the extension related part
|(zend_)?extension(_debug)?(_ts)?)[\t\ ]*='
completly ?

[petk]

Applied via 3ead672 to PHP-7.2+ with few slight adjustments...

Thank you @rhabacker for the patch.

[rhabacker]

Applied via 3ead672 to PHP-7.2+ with few slight adjustments...

This patch has been reverted, see 3ead672#commitcomment-32840691, so the issue is still present.