This is meant to resolve the dependency on DYLD_FRAMEWORK_PATH in iOS builds for testing, both on simulator and on device. Simulator testing still needs to adopt the environment variables of the host since these environment variables contain other data crucial to testing.
Created attachment 298379 [details] Patch
Created attachment 298380 [details] Patch
Created attachment 298383 [details] Patch
Created attachment 298385 [details] Patch
Created attachment 298415 [details] Patch
(In reply to comment #0) > This is meant to resolve the dependency on DYLD_FRAMEWORK_PATH in iOS builds > for testing, both on simulator and on device. Can you explain how DYLD_FRAMEWORK_PATH is currently used to facilitate testing, and what about it needs to be resolved?
(In reply to comment #6) > (In reply to comment #0) > > ... > > Can you explain how DYLD_FRAMEWORK_PATH is currently used to facilitate > testing, and what about it needs to be resolved? Currently, we run the LayoutTests on iOS simulators by setting SIMCTL_CHILD_DYLD_FRAMEWORK_PATH to the path of the build directory (i.e., .../OpenSource/WebKitBuild/Release-iphonesimulator) before launching the target application. For simulator testing, this works fine, (although, note that there are some comments from Dan Bates in the simulator interface code about intention to remove this type of environment variable manipulation for simulator test runs) but for on device testing, this technique will not work. This patch is part of an incomplete series of patches which will enable testing on an iOS device. As another note, there are a number of features of JavaScriptCore which will not be available on a device when the frameworks are packed and linked with the method proposed in this patch. This is due to some of iOS's sandboxing, there is no intention of making these features functional for on-device testing.
Is the issue that the location of the built frameworks relative to the executable not fixed?
(In reply to comment #8) > Is the issue that the location of the built frameworks relative to the > executable not fixed? That relationship isn't going to be fixed on either simulator or device, because the apps are installed before being launched. For simulator, there is a bit of an asterisk by this statement though, because while the executable is not in the build directory when run (like it would be for Mac) it is in a predictable location relative to the built frameworks (based on device ID). This patch moves the frameworks into the app bundle and links them locally so that on both simulator and device, this relationship is fixed and not dependent on device ID. To reiterate, while this patch simplifies the linking of DumpRenderTree and WebKitTestRunner for simulator testing, the method using DYLD_FRAMEWORK_PATH and absolute paths (which is currently being used) is sufficient for simulator testing. It is on-device testing which needs this local linking to run.
Jonathan explained told me in person more about how this proposed change fits into what he’s trying to do. I still wonder, though, if perhaps there is a way to defer the steps of copying the frameworks into the apps to the point where the apps are going to be installed, rather than doing it at build time on every build. In particular, it seems to me like with the patch as it is, no-op builds (i.e. building the app again after making no changes since the last build) are going to take significantly longer.
(In reply to comment #10) > ... no-op builds (i.e. > building the app again after making no changes since the last build) are > going to take significantly longer. This is a really good point. I put this inside the build process because xctest needs to be aware of it. I will look into making sure this script doesn't take up time on no-op builds along with a few other changes. Removing the review flag for the time being.
Created attachment 299153 [details] Patch
Created attachment 299158 [details] Patch
So this approach will not work. XPC services cannot be launched from inside an iOS app bundle.