Provide pre-built Windows debug binaries

[ranvis]

Description

ARG_ENABLE('debug', ...); is defined in two places: phpize.js.in and config.w32.phpize.in.
It makes user not possible to activate --enable-debug on configureing an extension because the latter definition overwrites PHP_DEBUG back to the default false.

The following code:

path\to\phpize
configure.bat --enable-debug --enable-extensionname

Resulted in this output:

---------------------------------------
| Build type        | Release         |
...

But I expected this output instead:

---------------------------------------
| Build type        | Debug           |
...

PHP Version

PHP 8.1.3

Operating System

No response

[cmb69]

It makes user not possible to activate --enable-debug on configureing an extension because the latter definition overwrites PHP_DEBUG back to the default false.

Isn't that actually desired? If I --enable-debug for an extension using a release PHP build, linking is usually going to fail. Same the other way round. So it seems to me that we should rather remove the --enable-debug option from phpize builds at all.

[ranvis]

Hmm, looks like what I expected was not what --enable-debug for extensions provides.
I didn't meant to link against the different php.lib than generated phpize script expects, but to disable optimization or to define _DEBUG, like in CMake+Visual Studio targetting "Debug" instead of "Release" or "RelWithDebInfo".
(In other words, by reading help I thought --enable-debug is "Debug" because --enable-debug-pack should be "RelWithDebInfo".)

By rewriting to ZEND_DEBUG=0 after configuring an extension with --enable-debug, it looks like to work; it builds and runs on release build PHP.
Is ZEND_DEBUG the whole point of making interface incompatible?
If so, for extensions I think ZEND_DEBUG can be propagated to say unconfigurable PHP_ZEND_DEBUG, so that --enable-debug can be retained?

[cmb69]

Well, --enable-debug is pretty close to "Debug" builds in Visual Studio, but the option also adds suffixes for libraries to link against (e.g. php8_debug.lib instead of php8.dll,, and for third-party libraries *_debug.lib files are linked if available).

Just defining ZEND_DEBUG=1 to be able to build with a release version would not try to link to the _debug.libs, but would still not work, since some functions exposed by the Zend Engine have different signatures for release and debug builds, respectively (e.g. efree() which includes the filename and lineno only for debug builds), and as such linking fails due to the name mangling for ZEND_FASTCALL.

Thus, I don't know whether it even would make sense to attempt such "mixed" builds. Why not just use release builds of extensions with release builds of php-src, and debug builds of extensions with debug builds of php-src?