RESOLVED DUPLICATE of bug 166814 165220
Sometimes some of the JS derived sources are not regenerated when their rules files change 
https://bugs.webkit.org/show_bug.cgi?id=165220
Summary Sometimes some of the JS derived sources are not regenerated when their rules...
Said Abou-Hallawa
Reported 2016-11-30 14:15:15 PST
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
Comment 1 2016-11-30 14:18:14 PST
Most notably and frequently, removing things from Settings.in is a recipe for disaster.
Alexey Proskuryakov
Comment 2 2016-12-01 10:22:03 PST
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
Comment 3 2016-12-01 10:27:10 PST
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)
Comment 4 2016-12-01 10:37:49 PST
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
Comment 5 2016-12-01 10:49:43 PST
Note that I made some progress fixing this recently for JS: - https://trac.webkit.org/changeset/205913
Andy Estes
Comment 6 2016-12-16 16:13:57 PST
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
Comment 7 2016-12-16 16:18:20 PST
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
Comment 8 2016-12-17 17:39:03 PST
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
Comment 9 2017-02-08 17:10:57 PST
Is this a duplicate of bug 166814?
Said Abou-Hallawa
Comment 10 2017-02-08 17:59:06 PST
Yes it is a duplicate of 166814. *** This bug has been marked as a duplicate of bug 166814 ***
Note You need to log in before you can comment on or make changes to this bug.