build: compile Xdebug 3.2.2 for PHP 8.0, 8.1, 8.2, fixes #6159

[stasadev]

The Issue

• Consider downgrade of php-xdebug, for #5633 #6159

How This PR Solves The Issue

Compiles Xdebug 3.2.2 library for PHP 8.0, 8.1, 8.2.

Unfortunately we can't build Xdebug 3.2.2 for PHP 8.3:

checking Check for supported PHP versions... configure: error: not supported. Need a PHP version >= 8.0.0 and < 8.3.0 (found 8.3.7)

Xdebug Compatibility https://xdebug.org/docs/compat

Manual Testing Instructions

# check Xdebug library files in DDEV HEAD
ddev exec ls -l $(ddev exec dpkg-query -L php{8.0,8.1,8.2}-xdebug | grep xdebug.so)
# or
docker run --rm -it ddev/ddev-php-base:20240513_stasadev_debsuryorg bash -c 'ls -l $(find / -iname xdebug.so)'

# check Xdebug library files in this PR
ddev exec ls -l /usr/lib/php/20200930/xdebug.so /usr/lib/php/20210902/xdebug.so /usr/lib/php/20220829/xdebug.so
# or
docker run --rm -it ddev/ddev-php-base:v1.23.1 bash -c 'ls -l $(find / -iname xdebug.so)'

ddev config --php-version 8.2 && ddev restart && ddev xdebug && ddev php -v
ddev config --php-version 8.1 && ddev restart && ddev xdebug && ddev php -v
ddev config --php-version 8.0 && ddev restart && ddev xdebug && ddev php -v

Automated Testing Overview

Related Issue Link(s)

Release/Deployment Notes

[stasadev]

I will make a new build of the Docker image only after the next PR goes in:

• build: install deb.sury.org key from debsuryorg-archive-keyring, fixes #6143 #6180

[stasadev]

And it can be tested manually using .ddev/web-build/Dockerfile

[rfay]

Please open an issue with https://bugs.xdebug.org/my_view_page.php explaining your results with php 8.3, thanks!

[stasadev]

Please open an issue with bugs.xdebug.org/my_view_page.php explaining your results with php 8.3, thanks!

It's not compatible (see https://xdebug.org/docs/compat) so they won't fix it.

[rfay]

Oh, I understand now, thanks.

[rfay]

This looks like the right strategy to me. We just have to do some good solid testing on multiple PHP versions with and without xdebug.

[stasadev]

I added a new stage for Xdebug, because the size of the Docker image ddev-php-base has grown significantly:

linux/amd64 333.86 MB => 426.51 MB
linux/arm64 327.2 MB => 414 MB

Also I added cleanup for /tmp/*, because there were leftovers from platformsh:

$ docker run --rm -it ddev/ddev-webserver:v1.23.0-1 ls -la /tmp
total 40
drwxrwxrwt 2 root root  4096 Apr 16 18:31 .
drwxr-xr-x 1 root root  4096 May 14 10:54 ..
-rw-r--r-- 1 root root  4891 Apr 16 18:30 platformsh-install-20240416-183042.log
-rw-r--r-- 1 root root  4862 Apr 16 18:30 platformsh-install-20240416-183049.log
-rw-r--r-- 1 root root 14880 Apr 16 18:30 setup.deb.sh

Building a new image.

[rfay]

I was thinking about that last night, about build-essential getting into the final image. Thanks for catching that!

[rfay]

There is a question remaining: If we can't downgrade for PHP8.3... should we still be downgrading for PHP8.1/2?

[stasadev]

If we can't downgrade for PHP8.3... should we still be downgrading for PHP8.1/2?

It is still supported https://www.php.net/supported-versions.php
If this PR works, it could make life easier for people who have PHP8.0/1/2.

[rfay]

Oh, dear, I didn't look at the right thing, did I? That was a previous push. The current ddev-php-base is much too big:

[rfay]

Oh, I see you were already building as we spoke.

[stasadev]

Yes, but it failed after 30 minutes (connection timeout to php repo), I just restarted it again.

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR.

[stasadev]

I ran a basic debugging session with a single breakpoint and step over, using PHP 8.0, 8.1, 8.2.

Used Linux amd64 with PhpStorm 2023.3.6.

And tested Xdebug 3.3.2 with PHP 8.3 to make sure it works the same for me.

[rfay]

So much better, thanks!:

[stasadev]

And this works too, so we don't limit everyone to 3.2.2:

webimage_extra_packages: ['php${DDEV_PHP_VERSION}-xdebug']

[rfay]

I think we're good to go on this. You've tested carefully manually, I tested a couple of ways, code looks good. It's more complicated than I hoped, and I hope we can remove it at some point. I love the commenting, which reduces the fear factor of introducing this.

[rfay]

These should both be ENV shouldn't they? Don't bother changing it, but they're not ARGS into the build are they? They way you have it they're just taking the assigned value because there is no ARG of this name.

[stasadev]

Well, I used ARG because we don't want these variables to be inside the container:

$ docker run --rm -it ddev/ddev-php-base:v1.23.1 bash -c 'echo $XDEBUG_VERSION'
(nothing here)

See Docker ARG vs ENV.

But when you declare it with ENV, it will be available inside, e.g.:

$ docker run --rm -it ddev/ddev-php-base:v1.23.1 bash -c 'echo $php83_arm64'
apcu bcmath bz2 curl cli common fpm gd imagick intl ldap mbstring memcached mysql opcache pgsql readline redis soap sqlite3 uploadprogress xdebug xhprof xml xmlrpc zip

I think it doesn't really matter here, since ddev/ddev-php-base isn't what users end up with, it's empty anyway:

$ docker run --rm -it ddev/ddev-webserver:v1.23.1 bash -c 'echo $php83_arm64'
(nothing here)

[rfay]

That is awesome, thanks, always great to learn from you! I always use them only for when there's a --build-arg one way or another, but this is a great differentiator.

[rfay]

This is scary wild stuff!

[rfay]

Thanks for the excellent commenting.