Bug 165220
| Summary: | Sometimes some of the JS derived sources are not regenerated when their rules files change | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Said Abou-Hallawa <sabouhallawa> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | aestes, ap, cdumez, darin, dbates, lforschler, mitz, ryanhaddad, simon.fraser, thorton |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=166814 | ||
Said Abou-Hallawa
This happens locally and on the EWS bots. Example is https://bugs.webkit.org/show_bug.cgi?id=165177.
A clean build fixes the issue.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Tim Horton
Most notably and frequently, removing things from Settings.in is a recipe for disaster.
Alexey Proskuryakov
When this happens, it happens on all bots. But in a couple of times I tried to reproduce this locally, this didn't reproduce.
Chris Dumez
So based on Said and Tim's comment it seems the main issue is Settings.in (and not JS bindings). I got confused because of "JS derived sources" in the title.
Simon Fraser (smfr)
I saw this regularly when changing Settings.in. I think there's some issue with the generated .idl file that's used to create JSInternalSettingsGenerated.*
Chris Dumez
Note that I made some progress fixing this recently for JS:
- https://trac.webkit.org/changeset/205913
Andy Estes
I was able to reproduce this by removing a setting from Settings.in and rebuilding. I saw the following output in WebCore's Derived Sources build phase:
perl WebCore/page/make_settings.pl --input WebCore/page/Settings.in
make: Nothing to be done for `all'.
Afterwards, InternalSettingsGenerated.h still had declarations for the setting I removed (shouldSuppressKeyboardInputDuringProvisionalNavigation).
Make printed the command to bring InternalSettingsGenerated.h up-to-date, but didn't seem to actually run it.
Andy Estes
Actually make_settings.pl did run, because SettingsMacros.h no longer contained the removed setting. It just seems like the internal generated settings weren't updated.
Darin Adler
Very surprising that make_settings.pl was able to successfully modify SettingsMacros.h but not InternalSettingsGenerated.h. Perhaps the script failed part way through: The script does update SettingsMacros.h first, and then InternalSettingsGenerated.h later, but it seems like a peculiar symptom.
Alexey Proskuryakov
Is this a duplicate of bug 166814?
Said Abou-Hallawa
Yes it is a duplicate of 166814.
*** This bug has been marked as a duplicate of bug 166814 ***