WebKit daemons live inside the WebKit framework. However, we can't start these daemons during testing because they live outside the runtime root of the simulator. If we symlink our daemons into the simulator runtime root, we can safely test them.
<rdar://problem/85362551>
Created attachment 444125 [details] Patch
Pull-request: https://github.com/WebKit/WebKit/pull/38
Comment on attachment 444125 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=444125&action=review > Tools/Scripts/webkitpy/api_tests/manager.py:156 > + # Daemons can't be called from outside the runtime root I would phrase a bit differently, like: "A Daemons executable path must be located within the runtime root"
Comment on attachment 444125 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=444125&action=review > Tools/ChangeLog:3 > + [webkitpy] Symlink daemons into simulator runtime root Does this modify what's inside /Applications/Xcode.app? If so, this seems very undesirable.
(In reply to Alexey Proskuryakov from comment #5) > Comment on attachment 444125 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=444125&action=review > > > Tools/ChangeLog:3 > > + [webkitpy] Symlink daemons into simulator runtime root > > Does this modify what's inside /Applications/Xcode.app? If so, this seems > very undesirable. Yes, not sure there is another way to do this, though. Simulators can't interact with daemons outside of their runtime root. We're sticking the binaries in a place that shouldn't effect anything.
(In reply to Jonathan Bedard from comment #6) > (In reply to Alexey Proskuryakov from comment #5) > > Comment on attachment 444125 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=444125&action=review > > > > > Tools/ChangeLog:3 > > > + [webkitpy] Symlink daemons into simulator runtime root > > > > Does this modify what's inside /Applications/Xcode.app? If so, this seems > > very undesirable. > > Yes, not sure there is another way to do this, though. Simulators can't > interact with daemons outside of their runtime root. We're sticking the > binaries in a place that shouldn't effect anything. Right. We chose a symlink location that has zero chance of conflicting with any other built-in file that might end up in a future runtime root, and a near-zero chance of affecting anything else with the runtime. To test our daemons (which is a quite desirable thing to do) we have no other identified options.
Landed https://commits.webkit.org/244216@main (r285772)! If we come up with a better technique in the coming weeks, happy to remove this. I think it's important to unblock testing for now, though.
(In reply to Jonathan Bedard from comment #8) > Landed https://commits.webkit.org/244216@main (r285772)! > > If we come up with a better technique in the coming weeks, happy to remove > this. I think it's important to unblock testing for now, though. This patch worked for you locally, for me locally, and for EWS here when you put the patch in the queue. But with my patch over in https://bugs.webkit.org/show_bug.cgi?id=232982 it fails to do the link: https://ews-build.webkit.org/#/builders/9/builds/58765
I think that this is strictly unacceptable, whether there is another solution or not. I will be reverting this change.
Reverted r285772 for reason: Ownership issues in some XCode installs Committed r285779 (244223@main): <https://commits.webkit.org/244223@main>
Reverted the change because it didn't unblock Brady anyways and I think Brady's patch meant that this change was breaking some EWS queues. I do think that symlinking is still the right approach, but let's figure out our options next week.
Created attachment 444276 [details] Patch
Brady found another way to solve this problem, closing this bug.