Fix phpize on windows

[bwoebi]

It seems like n === undefined must have worked on older versions of jscript, but currently it just causes the insertion to silently fail. This sets n to the current folder name, allowing phpize to include the local config.w32 files.
This just affects the standalone extension build mechanism.

Basing it on PHP 8.1, as it's purely build system. If that's wrong I'll just change the target to PHP-8.3.

[cmb69]

Ugh, they've lost their mind.

Can you please provide the output when you run the following script (I'm getting 5.8.16384):

WScript.StdOut.WriteLine(ScriptEngineMajorVersion() + "." + ScriptEngineMinorVersion() + "." + ScriptEngineBuildVersion());

It seems like n === undefined must have worked on older versions of jscript,

That was not reliable (prior to ECMAScript 5, or something, you could assign to undefined); see e.g.

undefined = 42;
WScript.StdOut.WriteLine(undefined);

Would typeof n === "undefined" work for you (or is that check somewhere in phpize.js?)

[cmb69]

Would typeof n === "undefined" work for you (or is that check somewhere in phpize.js?)

Oops, nonsense. I see now. Would n === "" still work?

[cmb69]

Anyway, the fix as is might break extensions with the following structure (not sure if something like this is currently properly supported, though):

foo
|   config.w32
|
\---foo
        config.w32

[bwoebi]

Assigning an empty string would also work I suppose (or just a dot), but the key is also used for the output in gen_modules, which was anyway a bit weird that it's empty.
That's why I chose the folder name, for the proper display?

I can't reproduce this right now myself as I'm running Windows 10; it was on somebody elses machine I don't have access to.

[cmb69]

While I consider passing an empty module string a bug, I would like to keep any bugfix impact as small as possible (see #17759 (comment)), especially when we're targeting 8.1 (not sure if that would be okay, though; RM decision: @ramsey, @patrickallaert). Thus I would prefer using an empty string for now; using the folder name might better be left to master, or maybe PHP-8.4.

It might make sense to double-check this on the windows-2025 GH hosted runners; these appear to run 24H2. Indeed: https://github.com/php/pecl-database-dbase/actions/runs/13251601748/job/36990497338#step:6:88. At least, there appears to be a workaround: https://github.com/php/pecl-database-dbase/actions/runs/13252016459/job/36991776017#step:5:1 (yeah, IE is alive! ;) Might be worth documenting that, since there may be more incompatibilities with our Windows build chain.

[patrickallaert]

While I consider passing an empty module string a bug, I would like to keep any bugfix impact as small as possible (see #17759 (comment)), especially when we're targeting 8.1 (not sure if that would be okay, though; RM decision: @ramsey, @patrickallaert). Thus I would prefer using an empty string for now; using the folder name might better be left to master, or maybe PHP-8.4.

Totally agreed on my side!

[bwoebi]

Sounds good by me, let's use the empty string then (updated).

[cmb69]

Closed via 7f6c051. Thanks for the PR!