Bug 193792 – Add .xcfilelists to Run Script build phases

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Keith Rollin]

As part of supporting XCBuild, update the necessary Run Script build phases in their Xcode projects to refer to their associated .xcfilelist files.

Make special accommodations for incorporation .xcfilelists from WebKitAdditions.

[Keith Rollin]

<rdar://problem/47201785>

[Keith Rollin]

Created attachment 360181 [details]
Patch

[Alex Christensen]

Comment on attachment 360181 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=360181&action=review

> Source/WebKit/Configurations/DebugRelease.xcconfig:64
> +WK_WEBKIT_ADDITIONS_PATH = ../../../Internal/WebKit/WebKitAdditions/Additions/WebKit

What's this used for?  It looks iffy.

> Tools/DumpRenderTree/DumpRenderTree.xcodeproj/project.pbxproj:6
> -	objectVersion = 46;
> +	objectVersion = 51;

What happens if we don't make this change?

[Keith Rollin]

(In reply to Alex Christensen from comment #3)
> Comment on attachment 360181 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=360181&action=review
> 
> > Source/WebKit/Configurations/DebugRelease.xcconfig:64
> > +WK_WEBKIT_ADDITIONS_PATH = ../../../Internal/WebKit/WebKitAdditions/Additions/WebKit
> 
> What's this used for?  It looks iffy.

This is for the case where we're in the Xcode IDE and doing a full workspace build. When that happens, XCBuild creates a build plan for all projects simultaneously. In order to do that, it needs to find all the .xcfilelist files. The WebKitAdditions step has not had a chance to run yet, so we can't find the WebKitAdditions .xcfilelist files in whatever temp directory it ultimately gets copied to. In order to find the .xcfilelists, we need to tell XCBuild the source location for them.


> > Tools/DumpRenderTree/DumpRenderTree.xcodeproj/project.pbxproj:6
> > -	objectVersion = 46;
> > +	objectVersion = 51;
> 
> What happens if we don't make this change?

I haven't tried. But I believe that one thing that will happen is that they will get updated again the next time someone touches the project.

The bumping of this version number essentially scraps compatibility with the IDE from Xcode 9 (building from the command line still works). I've checked with a number of stakeholders, and they're mostly OK with that.

[Alex Christensen]

(In reply to Keith Rollin from comment #4)
> (In reply to Alex Christensen from comment #3)
> > Comment on attachment 360181 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=360181&action=review
> > 
> > > Source/WebKit/Configurations/DebugRelease.xcconfig:64
> > > +WK_WEBKIT_ADDITIONS_PATH = ../../../Internal/WebKit/WebKitAdditions/Additions/WebKit
> > 
> > What's this used for?  It looks iffy.
> 
> This is for the case where we're in the Xcode IDE and doing a full workspace
> build. When that happens, XCBuild creates a build plan for all projects
> simultaneously. In order to do that, it needs to find all the .xcfilelist
> files. The WebKitAdditions step has not had a chance to run yet, so we can't
> find the WebKitAdditions .xcfilelist files in whatever temp directory it
> ultimately gets copied to. In order to find the .xcfilelists, we need to
> tell XCBuild the source location for them.

I don't think we should make the open source repository that dependent on internal structure of the internal repository.  I think we should stop at ../../../Internal or maybe ../../../Internal/WebKit and put logic in Internal to handle it.

[Keith Rollin]

(In reply to Alex Christensen from comment #5)
> I don't think we should make the open source repository that dependent on
> internal structure of the internal repository.  I think we should stop at
> ../../../Internal or maybe ../../../Internal/WebKit and put logic in
> Internal to handle it.

Could you elaborate? Does this mean storing the .xcfilelists directly in Internal or Internal/WebKit? That's the only way I can imagine implementing your suggestion. But we can't "put logic in Internal to handle it" because any logic that we implement will not execute before those files are needed. When you hit Build in Xcode, it's going to look for those .xcfilelists before executing any actual build steps, because it needs the information in those files in order to determine what build steps to execute.

Also, putting those files in Internal or Internal/WebKit would put those files outside of the project that likely would hold the logic for handling them. Does Xcode support a structure like that? Do our company build tools? I would hope so, but I wouldn't be surprised if they didn't.

[Keith Rollin]

Another patch coming soon. I realized that the current patch adds the .xcfilelists for the Derived Sources phases, but I forgot to add those for the Generate Unified Sources phases. The new patch will include that change, but doesn't respond to Alex's comments until we figure out what the solution will look like.

[Keith Rollin]

Created attachment 360394 [details]
Patch

[Alex Christensen]

Comment on attachment 360394 [details]
Patch

I don't like this, but then again I don't like the whole direction the build system is going in.  If anyone complains, I'll send them to you.  R=me for this patch.

[WebKit Commit Bot]

Comment on attachment 360394 [details]
Patch

Clearing flags on attachment: 360394

Committed r240668: <https://trac.webkit.org/changeset/240668>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.