Bug 165220 - Sometimes some of the JS derived sources are not regenerated when their rules files change
Summary: Sometimes some of the JS derived sources are not regenerated when their rules...
Status: RESOLVED DUPLICATE of bug 166814
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-30 14:15 PST by Said Abou-Hallawa
Modified: 2017-02-08 17:59 PST (History)
10 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Said Abou-Hallawa 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.
Comment 1 Tim Horton 2016-11-30 14:18:14 PST 
Most notably and frequently, removing things from Settings.in is a recipe for disaster.
Comment 2 Alexey Proskuryakov 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.
Comment 3 Chris Dumez 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.
Comment 4 Simon Fraser (smfr) 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.*
Comment 5 Chris Dumez 2016-12-01 10:49:43 PST 
Note that I made some progress fixing this recently for JS:
- https://trac.webkit.org/changeset/205913
Comment 6 Andy Estes 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.
Comment 7 Andy Estes 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.
Comment 8 Darin Adler 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.
Comment 9 Alexey Proskuryakov 2017-02-08 17:10:57 PST 
Is this a duplicate of bug 166814?
Comment 10 Said Abou-Hallawa 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 ***