[Webkit-unassigned] [Bug 235744] [XCBuild] WTF's headers are copied via a script and are invisible to the build system

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=235744

--- Comment #18 from Elliott Williams <emw at apple.com> ---
(In reply to Alexey Proskuryakov from comment #15)
> Modifying source is sad. I understand that we have precedent, but I'd like
> to understand more about why it's OK - why we can never encounter read-only
> source, and why this won't cause SCM conflicts on bots as local changes
> clash with checkouts.

It's "OK" because the xcfilelists should not change, absent changes to the script's inputs. The precedent we have for this behavior (generate_xcfilelists_lib) tries to force devs to catch and commit changes, by...

- Failing the build when the xcfilelists _do_ change, so it's not possible for the files to silently get mutated on a CI machine. 
- Checking (and potentially regenerating) xcfilelists in every build, so that regenerations are caught early.

In the status quo, it's possible to send a patch to EWS that regenerates xcfilelists, but that would mean you had _never_ completed a build at your desk first. I'm guessing that doesn't happen often, which is why we don't regularly see source conflicts on CI machines.

--

With this in mind, I think I should reimplement my rsync generator as part of generate_xcfilelists_lib, so that we stick to all the same xcfilelist behaviors and guarantees that we have been living with.

Does that sound reasonable, or do you think I should abandon this and instead land the native build phase approach from the first patch?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220205/2792731c/attachment.htm>