Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On Windows, the cli and phpdbg SAPIs have variants (cli-win32 and phpdbgs, respectively) which are build by default. However, the variants share some files, what leads to duplicate build rules in the generated Makefile. NMake throws warning U4004[1], but proceeds happily, ignoring the second build rule. That means that different flags for duplicate rules are ignored, hinting at a potential problem.
We solve this by introducing an additional (optional) argument to
SAPI()
andADD_SOURCES()
which can be used to avoid such duplicate build rules. It's left to the SAPI maintainers to make sure that appropriate rules are created. We fix this for phpdbgs right away, which currently couldn't be build without phpdbg due to the missing define; we remove the unusedPHP_PHPDBG_EXPORTS
flag altogether.[1] https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/nmake-warning-u4004
Note that I tried to solve this without even touching confutils.js, but failed. While this solution isn't particularly great, it solves the duplicate rules problem without any BC implications for users.
Also note that
PHPDBG_API
is not properly handled on Windows; due to missing__declspec(dllimport)
there is a minimal performance impact, and variables couldn't be accessed at all (but there are none anyway). I'll try to follow up with a "fix".