Bug 178225 – Xcode build should parallelize targets

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Keith Miller]

We should figure out why we can't do this now and what we need to change to fix this. This hasn't been attempted in a long time so there's a lot of unknowns here. Also, since the command line build doesn't use schemes we should see if you can parallelize the build there too.

[Radar WebKit Bug Importer]

<rdar://problem/34960577>

[Andy Estes]

I was able to improve the full build time in a workspace by 20% with this option enabled. It required some project changes that I'll post a patch for here.

It's also possible to parallelize the targets within each project when building from the command line with the "Parallelize build for command-line builds" project option, but that's not as fast as allowing full target parallelization across a workspace of projects.

We could make the command line build faster by invoking a different xcodebuild command, like `xcodebuild -workspace WebKit.workspace -scheme "All Tools"`, when make is run from a directory containing a workspace. Building the "All Tools" scheme with "Find Implicit Dependencies" enabled is equivalent to what `make debug` from the root directory, for instance.

[Keith Miller]

(In reply to Andy Estes from comment #2)
> We could make the command line build faster by invoking a different
> xcodebuild command, like `xcodebuild -workspace WebKit.workspace -scheme
> "All Tools"`, when make is run from a directory containing a workspace.
> Building the "All Tools" scheme with "Find Implicit Dependencies" enabled is
> equivalent to what `make debug` from the root directory, for instance.

Does building with a full workspace cause TestWTF to be built very early in the build? Whenever I've built with our internal build I noticed that it built right away. I'd be nice (at least for jsc devs) if that was done after the rest of the JSC build.

That said, maybe we should just have a JSC CLI build target... 🤷‍♂️

(In reply to Keith Miller from comment #3)
>
> Does building with a full workspace cause TestWTF to be built very early in
> the build? Whenever I've built with our internal build I noticed that it
> built right away. I'd be nice (at least for jsc devs) if that was done after
> the rest of the JSC build.

Is that desirable for efficiency or is there actually a TestWTF dependency on JSC that Xcode doesn’t know about?

[Keith Miller]

(In reply to mitz from comment #4)
> (In reply to Keith Miller from comment #3)
> >
> > Does building with a full workspace cause TestWTF to be built very early in
> > the build? Whenever I've built with our internal build I noticed that it
> > built right away. I'd be nice (at least for jsc devs) if that was done after
> > the rest of the JSC build.
> 
> Is that desirable for efficiency or is there actually a TestWTF dependency
> on JSC that Xcode doesn’t know about?

No, just efficiency. I don't know of any true dependency. FWIW, if you're trying to test WTR you also don

[Keith Miller]

(In reply to Keith Miller from comment #5)
> (In reply to mitz from comment #4)
> > (In reply to Keith Miller from comment #3)
> > >
> > > Does building with a full workspace cause TestWTF to be built very early in
> > > the build? Whenever I've built with our internal build I noticed that it
> > > built right away. I'd be nice (at least for jsc devs) if that was done after
> > > the rest of the JSC build.
> > 
> > Is that desirable for efficiency or is there actually a TestWTF dependency
> > on JSC that Xcode doesn’t know about?
> 
> No, just efficiency. I don't know of any true dependency. FWIW, if you're
> trying to test WTR you also don

Ugh, Tab+enter in the text field is a bad combo... lol

don't want to burn CPU cycles building TestWTF first.

[Andy Estes]

(In reply to Keith Miller from comment #3)
> (In reply to Andy Estes from comment #2)
> > We could make the command line build faster by invoking a different
> > xcodebuild command, like `xcodebuild -workspace WebKit.workspace -scheme
> > "All Tools"`, when make is run from a directory containing a workspace.
> > Building the "All Tools" scheme with "Find Implicit Dependencies" enabled is
> > equivalent to what `make debug` from the root directory, for instance.
> 
> Does building with a full workspace cause TestWTF to be built very early in
> the build? Whenever I've built with our internal build I noticed that it
> built right away. I'd be nice (at least for jsc devs) if that was done after
> the rest of the JSC build.
> 
> That said, maybe we should just have a JSC CLI build target... 🤷‍♂️

There isn't a way to build the full workspace, per se. You create a scheme that lists the targets you want to build, and Xcode builds just those targets and their dependencies (incl. dependent targets from other workspace projects when "Find Implicit Dependencies" is enabled).

Existing WebKit.xcworkspace schemes like "All Tools" might build both TestWebKitAPI and TestWTF, but you can always create your own scheme that builds just the targets you want.

[Andy Estes]

(In reply to mitz from comment #4)
> (In reply to Keith Miller from comment #3)
> >
> > Does building with a full workspace cause TestWTF to be built very early in
> > the build? Whenever I've built with our internal build I noticed that it
> > built right away. I'd be nice (at least for jsc devs) if that was done after
> > the rest of the JSC build.
> 
> Is that desirable for efficiency or is there actually a TestWTF dependency
> on JSC that Xcode doesn’t know about?

Despite its name, for the purposes of parallelizing targets TestWTF depends on WebKit just like TestWebKitAPI does, because both share the same config.h that includes WebKit headers (although that could be fixed).

[Andy Estes]

Created attachment 409427 [details]
Patch for EWS

[Andy Estes]

Created attachment 409437 [details]
Enable "Parallelize Build" option in WebKit.xcworkspace

[Andy Estes]

Created attachment 409438 [details]
Enable "Parallelize Build" option in WebKit.xcworkspace

[Andy Estes]

Created attachment 409439 [details]
Enable "Parallelize Build" option in WebKit.xcworkspace

Comment on attachment 409439 [details]
Enable "Parallelize Build" option in WebKit.xcworkspace

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

> WebKit.xcworkspace/contents.xcworkspacedata:50
> +      location = "group:../Internal/WebKit/WebKitAdditions/WebKitAdditions.xcodeproj">

Is this going to create any problems for folks who don’t have Internal?

[Andy Estes]

Comment on attachment 409439 [details]
Enable "Parallelize Build" option in WebKit.xcworkspace

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

> Source/JavaScriptCore/ChangeLog:25
> +        dependent target's products from the build directory. If this build phase has the

s/dependent/depended-on/

[Andy Estes]

(In reply to mitz from comment #13)
> Comment on attachment 409439 [details]
> Enable "Parallelize Build" option in WebKit.xcworkspace
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=409439&action=review
> 
> > WebKit.xcworkspace/contents.xcworkspacedata:50
> > +      location = "group:../Internal/WebKit/WebKitAdditions/WebKitAdditions.xcodeproj">
> 
> Is this going to create any problems for folks who don’t have Internal?

My expectation is no, but I need to test.

Comment on attachment 409439 [details]
Enable "Parallelize Build" option in WebKit.xcworkspace

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

> Source/JavaScriptCore/ChangeLog:26
> +        "Run script only when installing" option enabled and exists in a target with SKIP_INSTALL=YES

“Copy only when installing”

Comment on attachment 409439 [details]
Enable "Parallelize Build" option in WebKit.xcworkspace

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

> Source/JavaScriptCore/ChangeLog:29
> +

It looks like in production builds (when invoked with `xcodebuild install` and therefore DEPLOYMENT_LOCATION is `YES`), Xcode will still perform a copy into somewhere in OBJROOT or some temporary location, since SKIP_INSTALL doesn’t mean that the target doesn’t get built, only that it doesn’t get put directly into DSTROOT. I didn’t test this extensively, but if you’re seeing the same effect and you think it’s undesirable, one way that I’ve found to cancel it out is to exclude the file using EXCLUDED_SOURCE_FILE_NAMES. Implicit dependency tracking doesn’t check that, but copy phase processing does.

[Andy Estes]

(In reply to Andy Estes from comment #15)
> (In reply to mitz from comment #13)
> > Comment on attachment 409439 [details]
> > Enable "Parallelize Build" option in WebKit.xcworkspace
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=409439&action=review
> > 
> > > WebKit.xcworkspace/contents.xcworkspacedata:50
> > > +      location = "group:../Internal/WebKit/WebKitAdditions/WebKitAdditions.xcodeproj">
> > 
> > Is this going to create any problems for folks who don’t have Internal?
> 
> My expectation is no, but I need to test.

I don't think this creates problems.

Xcode ignores missing projects when opening a workspace, and none of this project's targets are in any of the shared schemes. When Copy WTF Headers builds, it fails to find a project that can build the libWebKitAdditionsPlaceholder.a product, but otherwise continues to treat the Build Workspace Products phase as just a no-op.

[Andy Estes]

(In reply to Andy Estes from comment #18)
> I don't think this creates problems.

(In reply to mitz from comment #17)
> Xcode will still perform a copy into somewhere in OBJROOT or some temporary
> location, since SKIP_INSTALL doesn’t mean that the target doesn’t get built,
> only that it doesn’t get put directly into DSTROOT.

In that case, non-existent workspace products create problems :)

A Product > Archive build in Xcode seems to show one of them. Surprisingly, the tool I used to build this patch for Production did not fail, or even show the "Build Workspace Products" phase running (in the places I checked for it).

Thank you for pointing this out. I'll post a new patch that uses EXCLUDED_SOURCE_FILE_NAMES for these products.

[Keith Rollin]

Please be sure to test with XCBuild. XCBuild is all about the dependencies, and since you're fiddling with those, it's a good idea to make sure you don't confound it. We've seen issues along these lines before.

To build with XCBuild:

* With `make`: Add `ARGS=-UseNewBuildSystem=YES` to the command line.
* With `build-webkit`: Add --xcbuild to the command-line.
* With production build scripts: Add --xcbuild to the command line.
* With Xcode: Make sure your patch is safely in git. Then set File > WorkSpace Settings... > Shared Workspace Settings > Build System = New Build System. This will change your workspace and projects in your working directory. By keeping these changes separate from your patch, you can easily revert them to their pre-XCBuild state so that you can submit just your changes.

[Andy Estes]

(In reply to Keith Rollin from comment #20)
> Please be sure to test with XCBuild.

I’ve successfully built this patch from both the workspace and make(1) using both the legacy and new build systems.

[Keith Rollin]

(In reply to Andy Estes from comment #21)
> (In reply to Keith Rollin from comment #20)
> > Please be sure to test with XCBuild.
> 
> I’ve successfully built this patch from both the workspace and make(1) using
> both the legacy and new build systems.

Awesome. You're a god.

[Andy Estes]

Created attachment 409478 [details]
Part 1 (for EWS)

[Saam Barati]

When this lands, will running `make release` just give me this faster build?

[Andy Estes]

Created attachment 409511 [details]
Part 1: Enable parallel schemes in WebKit.xcworkspace

[Andy Estes]

(In reply to Saam Barati from comment #24)
> When this lands, will running `make release` just give me this faster build?

Not in this first part, but I plan to post another patch that parallelizes `make` builds before I resolve this bug.

[Andy Estes]

Here is my plan for the `make` build:

1. The top-level Makefile will invoke `xcodebuild` once to build a parallel WebKit.xcworkspace scheme that builds everything. That build will be about as fast on the command line as it is in the Xcode UI.

2. Invoking make from other directories will continue to recursively build individual projects, but limited parallelism can be achieved by enabling "Parallelize build for command-line builds" in supported projects. Top-level workspace builds followed by recursive incremental rebuilds in sub-directories will be supported.

2a. I also considered having each project directory have a scheme in WebKit.xcworkspace that is built instead of the project itself, e.g., `make -C Source/JavaScriptCore` would rebuild workspace dependencies automatically before building JavaScriptCore. I'm worried this change would disrupt some workflows, though.

[Andy Estes]

2b. The Source/ and Tools/ top-level sub-directories are also candidates to build specially-crafted parallel workspace schemes rather than doing recursive `make`.

[Andy Estes]

Created attachment 409641 [details]
Part 1: Enable parallel schemes in WebKit.xcworkspace

[Andy Estes]

(In reply to Andy Estes from comment #29)
> Created attachment 409641 [details]
> Part 1: Enable parallel schemes in WebKit.xcworkspace

- Fixed an issue with building libwebrtc in parallel on the new build system.
- Fixed an issue where some JSC framework symlinks weren't created when building in parallel.

[Darin Adler]

Comment on attachment 409641 [details]
Part 1: Enable parallel schemes in WebKit.xcworkspace

I suppose the main issue here is that when you specify inputs and outputs we have to be sure both lists are exhaustive. I wasn’t able to audit each list. This is a welcome improvement, but will cause subtle failures if we left out any input or output files.

For example, in steps that execute scripts, we want to list the scripts themselves *plus anything they invoke, including perl modules as well as perl scripts and all the python sources*. I’m guessing you did all that carefully, but I am not sure!

[Elliott Williams]

This has been done in WebKit.xcworkspace since <https://bugs.webkit.org/show_bug.cgi?id=235385>, as part of our migration to XCBuild. build-webkit uses the parallel workspace build by default as of this week <https://bugs.webkit.org/show_bug.cgi?id=241298>.