-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Update include declaration in Dom css selectors #14752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hi Niels, I have included the patch in the local builds, I have another issue now:
|
I've pushed another commit that may fix the additional issue. |
Yes, that fixed the issue. Thank you so much :) |
Niels, For my understanding, could you explain why these issues are not detected by the CI? Why are we able to identify such issues when building with Nix? |
It seems you're building the extensions separately from each other and in a different directory structure. |
Fair enough, thanks! |
@drupol the root (php-src), main, TSRM and Zend are always required include directories for extensions. This change realistically also doesn't make sense from the separate build. Because including the ext/dom file in the middle of the library should ideally be done either with relative path #include "../../foo.h" or with #include <ext/dom/foo.h>. But for now we still use also this syntax #include "ext/dom/foo.h". I think that you'll sooner or later run into other issues. |
@petk shall I change the includes to relative paths then? I guess that would work too and also avoid the change I had to make to the windows build file. |
Yes, now I think understand. Separate build doesn't have the ext/dom headers available yet (if I understand this correctly). This will be issue also for phpize build. And the lexbor library could do the relative includes, yes. I think the relative includes are the way to go here. Good catch overall also for rechecking the libbcmath, pcrelib, libmbfl, and other bundled libraries. Edit: confirming the phpize build has the same issue. So, yes the relative includes will be better. |
Thanks for the insight. |
Using the very latest version of the branch has introduced a failing test:
|
@drupol Can you share the test output please? |
I wish I could, how do you do that? |
If you pass |
Just for the side info: other extensions are ok and all use the includes kind of ready for separate builds. Except ext/standard but this one is not problematic for now. |
Here's the issue:
|
Excellent. I'll have an eye on tomorrow morning's build and see if they passes. question: why 1d90544 was not part of this PR ? |
I didn't want to restart CI, and it was independent of fixing include-related problems. |
Fair enough, thanks for your great assistance! |
The next build is foreseen tomorrow at 5am, see it live in this repo: https://github.com/loophp/php-src-nix |
Thank you as well! |
Everything compiled successfully and has been automatically merged! loophp/php-src-nix#173 I really think having such a Nix based workflow directly in this repo could definitely be beneficial for contributors, to catch issues preemptively. |
Perhaps, although it's probably difficult to adapt what we have now to a different build system. Anyway thanks for checking. |
Just by adding a new Github Action workflow and a |
May fix 88da914#r143708340
@drupol Can you please check whether this resolves your issue? Thanks.