Bug 217371

Summary: Update post-processing rules for headers to not unnecessarily change timestamps
Product: WebKit Reporter: Keith Rollin <krollin>
Component: Tools / TestsAssignee: Keith Rollin <krollin>
Severity: Normal CC: aestes, darin, dino, eric.carlson, ews-watchlist, graouts, kbr, keith_miller, kondapallykalyan, mark.lam, msaboff, saam, sam, tzagallo, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Description Flags
Patch none

Description Keith Rollin 2020-10-06 02:34:22 PDT
Under XCBuild, the scripts employed in custom build rules can be invoked in innocuous situations. A common example is when the user is building from the command-line and they change the `make` output from stdout to a file, or vice-versa. Changing the output changes the setting of the COLOR_DIAGNOSTICS environment variable, which is enough to cause XCBuild to think something is different and that the custom build rule needs to be invoked. For the script's part, nothing significant has changed, yet it post-processes the header files, causing their modification dates to change, causing downstream rebuilds to occur.

Fix this problem by adopting an approach that doesn't modify the post-processed header files unless their contents actually change.
Comment 1 Radar WebKit Bug Importer 2020-10-06 02:34:35 PDT
Comment 2 Keith Rollin 2020-10-06 02:51:35 PDT
*** Bug 212444 has been marked as a duplicate of this bug. ***
Comment 3 Keith Rollin 2020-10-06 20:01:26 PDT
Created attachment 410726 [details]
Comment 4 EWS Watchlist 2020-10-06 20:02:31 PDT
Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE
Comment 5 Darin Adler 2020-10-07 08:30:18 PDT
Comment on attachment 410726 [details]

When I do something like this in a make file I end up creating a situation where there is even more rebuilding because there is no record the work was done. No risk of that here?
Comment 6 Keith Rollin 2020-10-07 10:57:25 PDT
I believe there is a small risk of what you describe. I think we can get into the situation you describe if the upstream/source files change their modification dates but not their actual contents. If that were to happen, these scripts would process those upstream files but not change the destination files. On the next build, the scripts would again get invoked, do their stuff, and not actually change anything. The destination's modification date would never be brought up-to-date with respect to the source files.

I'll address this by touching the destination files if the source files are newer, regardless of any actual content change. Doing this will cause an unnecessary rebuild, but it will happen only once, and the conditions under which this will happen should be extremely rare (why would the source file have its modification date changed without having its contents changed)?
Comment 7 Keith Rollin 2020-10-07 16:17:12 PDT
Created attachment 410796 [details]
Comment 8 EWS 2020-10-07 17:23:58 PDT
Committed r268163: <https://trac.webkit.org/changeset/268163>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 410796 [details].