[Webkit-unassigned] [Bug 236056] New: [Xcode] Remove xcfilelists from source control and generate them ahead-of-time

[bugzilla-daemon at webkit.org]

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

            Bug ID: 236056
           Summary: [Xcode] Remove xcfilelists from source control and
                    generate them ahead-of-time
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: emw at apple.com

Currently, the Xcode build unconditionally runs various "Check xcfilelist" script phases, which may modify xcfilelist sources in-place. Dirtying sources is bad, especially on a buildbot, because it can cause conflicts in SCM and precludes support for building from read-only sources.

The reason for checking these files into source control in the first place is because Xcode doesn't have a "configure" stage for each target like CMake does, where build system metadata like this can be generated ahead of time. However, Xcode does have Scheme "pre-actions", where scripts can be run before the formal start of the build, where dependencies are checked. We should investigate whether we can move xcfilelist generation into scheme actions and remove xcfilelists from source control.

Scheme actions will pose some challenges, namely:

1. They can't fail (rdar://88191278), and until recently could not log any output (rdar://8004230).
2. To get consistent behavior, we'd have to add a pre-build action for *each* scheme we ship. This would also make it harder for devs to create their own custom schemes for local use.
3. They have no input and output files, and therefore no built-in way to skip execution when they are up-to-date. So unless we call out to Make or some other build system, we really have to be confident our actions execute quickly.
4. They are scheme-specific, not target-specific. If a pre-action script uses build settings, it must pick *one* target to see settings from. So if N targets need to run some pre-action code using their build settings, we must add N scripts to a scheme. And if there are M different schemes that build the target, that's N*M pre-actions total. See #2 :\

-- 
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/20220203/c51917b8/attachment-0001.htm>