add xdebug dynamic extension

[henderkes]

What does this PR do?

see #672

Checklist before merging

If your PR involves the changes mentioned below and completed the action, please tick the corresponding option.
If a modification is not involved, please skip it directly.

• If you modified *.php, run composer cs-fix at local machine.
• If it's an extension or dependency update, make sure adding related extensions in src/global/test-extensions.php.
• If you changed the behavior of static-php-cli, update docs in ./docs/.
• If you updated config/xxx.json content, run bin/spc dev:sort-config xxx.

[henderkes]

This requires some work from your side. Technically these extensions don't have libraries but should have a build function themselves, rather than adding a library with the same name. I only went this route to get a proof of concept working quickly.

There's also no functionality to test these extensions yet. It could be done by adding a extension=$name to the php.ini, running make install in the $name source directory and then launching buildroot/bin/php (requires cli compilation) to check if it loads the extension.

[crazywhalecc]

Interesting. If it is confirmed to work for glibc and macOS, maybe it would be better to directly support this feature in Extension.php?

For example, when I build PHP, if I pass --with-shared-extensions=xdebug,XXX,YYY, Builder will call the buildShared() method in Extension.php after building the cli and verifying it. But we may also need to make additional adjustments to the doc structure, or only support one or a few extensions such as xdebug, and make special notes. What do you think?

Also, add "target": ["static", "shared"] for ext.json?

[henderkes]

Interesting. If it is confirmed to work for glibc and macOS, maybe it would be better to directly support this feature in Extension.php?

I cannot confirm macOS other than through github actions. I think we either use a different attribute (DynamicExt) because that way, we can distinguish which libraries/extensions need to be built before or after php. We could also support putting both attributes on an extension, that way it would be statically baked into php, but would also produce a .so extension to copy out.

For example, when I build PHP, if I pass --with-shared-extensions=xdebug,XXX,YYY, Builder will call the buildShared() method in Extension.php after building the cli and verifying it. But we may also need to make additional adjustments to the doc structure, or only support one or a few extensions such as xdebug, and make special notes. What do you think?

I think it would be nice for a few extensions. Treating it as a general possibility is better than hacking something together as I did for the proof of concept. This is your project and your decision about the way it's implemented.

My choice would be two different attributes and if an extension has #[DynamicExt] it'll be given a builder and a method will be called after. But we should reuse as much code as we can from the current dependency resolving system because dynamic extensions may also have library requirements.

Also, add "target": ["static", "shared"] for ext.json?

Yes, great idea. bin spc build "intl,pgsql" --with-shared="pgsql,xdebug" --build-embed --build-cli would bake pgsql into the php-cli/embed sapi, but also produce a pqsql.so that could be loaded dynamically.

Which... thinking about it... doesn't make all that much sense, I guess. But it doesn't hurt either, so why not.

[crazywhalecc]

It seems that some changes broke the dependency manager and I can't compile extension that contains ext-depends.

[crazywhalecc]

Everything looks good to me now, but I haven't fully tested all we added features.

[henderkes]

🥇