During the command line build of webkit on osx 10.11.4 box as an ios device target using Xcode 7.3 final the next error happens
Ld /Users/hofi/Develop/Others/WebKit/WebKitBuild/Release-iphoneos/WebCore.framework/WebCore normal arm64
ld: warning: directory not found for option '-F/xcode_7_3/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk/System/Library/PrivateFrameworks'
ld: framework not found GraphicsServices
clang: error: linker command failed with exit code 1 (use -v to see invocation)
** BUILD FAILED **
there is no Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk/System/Library/PrivateFrameworks folder in Xcode7.3
The source was the latest svn version after running the update-webkit with version info
Repository Root: https://svn.webkit.org/repository/webkit
Repository UUID: 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Node Kind: directory
Last Changed Author: email@example.com
Last Changed Rev: 198684
Last Changed Date: 2016-03-25 20:32:53 +0100 (Fri, 25 Mar 2016)
From briefly searching through the various .xccconfig files in the repository, we depend on the following iphoneos private frameworks that are not included with Xcode 7.3/iOS 9.3 public SDK:
We also depend on the following iphoneos libraries that are not included with Xcode 7.3/iOS 9.3 public SDK:
Created attachment 285916 [details]
Created attachment 285948 [details]
As suggested by Dan Bernstein, prefixed added custom Xcode build variables with "WK_" so as to make them stand out from the standard Xcode build variables. Also changed "--- !tapi-tbd-v2" to "---" in the iOS 9 .tbd files in an attempt to make the iOS EWS happy.
Created attachment 285978 [details]
Created attachment 285992 [details]
Attempt to fix up format of iOS 9 .tbd files to make ld(1), included in Xcode 7.3.1 (7D1014), happy.
Comment on attachment 285992 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=285992&action=review
> +FRAMEWORK_SEARCH_PATHS_base = $(WK_QUOTED_OVERRIDE_FRAMEWORKS_DIR);
> +FRAMEWORK_SEARCH_PATHS[sdk=iphone*] = $(FRAMEWORK_SEARCH_PATHS_base) $(WK_IOS_PRIVATE_SYMBOLS_DIR)
> +FRAMEWORK_SEARCH_PATHS = $(FRAMEWORK_SEARCH_PATHS_base);
No need to complicate the definition of FRAMEWORK_SEARCH_PATH so much.
First of all, a specialization can refer to the non-specialized value from the same level using $(inherited), so you could have just kept the existing definition of FRAMEWORK_SEARCH_PATH and added below it
FRAMEWORK_SEARCH_PATHS[sdk=iphone*] = $(inherited) $(WK_IOS_PRIVATE_SYMBOLS_DIR);
Furthermore, since WK_IOS_PRIVATE_SYMBOLS_DIR is empty when not targeting iOS, you could have just changed the definition of FRAMEWORK_SEARCH_PATHS to
FRAMEWORK_SEARCH_PATHS = $(WK_QUOTED_OVERRIDE_FRAMEWORKS_DIR) $(WK_IOS_PRIVATE_SYMBOLS_DIR);
This perhaps looks strange (referring to an iOS-specific build setting in a common build setting), but that can be fixed by choosing a better name for WK_IOS_PRIVATE_SYMBOLS_DIR, such as WK_PRIVATE_FRAMEWORK_STUBS_DIR (which I would do anyway).
> + * ios/ios-10-private-symbols/AppSupport.framework/AppSupport.tbd: Added.
> + * ios/ios-10-private-symbols/AssertionServices.framework/AssertionServices.tbd: Added.
> + * ios/ios-10-private-symbols/CorePDF.framework/CorePDF.tbd: Added.
> + * ios/ios-10-private-symbols/GraphicsServices.framework/GraphicsServices.tbd: Added.
> + * ios/ios-10-private-symbols/IOSurface.framework/IOSurface.tbd: Added.
> + * ios/ios-9-private-symbols/AppSupport.framework/AppSupport.tbd: Added.
> + * ios/ios-9-private-symbols/AssertionServices.framework/AssertionServices.tbd: Added.
> + * ios/ios-9-private-symbols/CorePDF.framework/CorePDF.tbd: Added.
> + * ios/ios-9-private-symbols/GraphicsServices.framework/GraphicsServices.tbd: Added.
> + * ios/ios-9-private-symbols/IOSurface.framework/IOSurface.tbd: Added.
I don’t like these directory names. I also think we shouldn’t be creating a directory called ios-…-private-symbols at the top level of the built products directory, since people may be sharing a built products directory with other non-WebKit-related projects. So in the built products directory, I’d prefer an organization like this:
Which leads me to think that under WebKitLibraries, the organization should be:
On second thought, I am not convinced that copying the files into the built products directory is even necessary or desirable. We do this static libraries because we process them (though we probably no longer have to) and because it streamlines the configuration by making it similar to the Apple-internal configuration where those libraries are built from source. But with the private framework stubs, could we just leave them in place and add their SRCROOT-relative location to the framework search paths? It would greatly simplify this patch.
Comment on attachment 285992 [details]
Will update patch to avoid copying stub files to the built products directory.
Created attachment 286045 [details]
Created attachment 286060 [details]
It looks like we can take advantage of the presence of the Xcode build setting TAPI_VERIFY_MODE to determine if Xcode supports text-based stubs.
Created attachment 286061 [details]
Committed r204471: <http://trac.webkit.org/changeset/204471>