Bug 124601 – Cannot build TestWebKitAPI target from within Xcode

• Component: Tools / Tests
• Status: NEW

[Brian Burg]

When selecting the "TestWebKitAPI" target in Xcode and building from a clean directory, several dependencies are not picked up by Xcode, thus the build fails.

This isn't an issue from command-line builds, ostensibly because of the compilation order.
If there isn't some other reason for the omissions below, then the patch should fix this.


Missing framework dependencies:

In WebKit:
 * WebCore.framework is missing group membership for target WebKit

In WebKit2:
 * Missing WebKit.framework (used by some mac port code)

In TestWebKitAPI:
 * Uses libgtest.a instead of gtest.framework, so Xcode can't figure how to build it.

[Brian Burg]

Created attachment 217335 [details]
v1

[Mark Rowe (bdash)]

Can you clarify what you're trying to fix here? Is it builds that are attempting to use only Xcode's "Find Implicit Dependencies" for building prerequisites rather than building the targets in the expected order?

[Brian Burg]

(In reply to comment #2)
> Can you clarify what you're trying to fix here? Is it builds that are attempting to use only Xcode's "Find Implicit Dependencies" for building prerequisites rather than building the targets in the expected order?

Exactly. As far as I can tell, building prerequisites from implicit dependencies is also attempted when running Tools/Scripts/run-api-tests on the command line, but it will fail somewhat inscrutably if you didn't happen to build other things already. 

I suppose another option is for the wrapper script to check for built products before building the API tests, but that seems to defeat the purpose of using xcodebuild to track dependencies.

[David Kilzer (:ddkilzer)]

Comment on attachment 217335 [details]
v1

The WebKit[1|Legacy] change seems fine, and the TestWebKitAPI change seems fine, but the WebKit2 change should probably be fixed a different way.  Do you know which headers WebKit2 depends on from WebKit[1|Legacy]?

r- because I think WebKit.framework has been renamed to WebKitLegacy.framework, and WebKit2.framework has been renamed to WebKit.framework, so the patch has likely bit-rotted.

[Mark Rowe (bdash)]

From what I can tell these changes do more than just changing dependency tracking: they also influence how Xcode will link the framework in question. Why would that be correct? If the problem is with Xcode's ability to find dependencies implicitly then perhaps the solution is to disable that option and specify the dependencies explicitly in the schema in question.