Dependencies: dynamically link XCTest #169
Conversation
|
Interesting, the tests pass with |
compnerd
force-pushed
the
dynamic
branch
2 times, most recently
from
b252523 to
a0c625b
Compare
|
Okay, preserving the existing behaviour on Darwin seems reasonable - the difference is the ObjC runtime is hooked dynamically already. The isolated library approach applies to non-ObjC runtimes (Linux, Windows). This I think might be down to 2 failures on Linux (which seem like a bug in the test case). |
compnerd
force-pushed
the
dynamic
branch
2 times, most recently
from
0a7b61e to
3508642
Compare
|
Taking a different approach to isolate the XCTest dependency, but without the SPI so conceptually simpler but with more indirection. I think that this is a better shape overall. Seems to pass on Linux and macOS. |
|
Ah, right, WASI does not yet do dynamic modules. What do you recommend here @stephencelis? |
|
@compnerd I haven't dug in too deeply, but can we fall back to explicit importing in this case? |
|
Okay, sure, I can make that change for WASI. |
Use delayed dynamic linking for registering the test observer. This is particularly important for Windows which does not support weak linking and weak symbols. Even in the case that `Dependencies` is imported due to use, we will not pull in the test observer until runtime, as a best effort. If the DependenciesTestObserver library is found in the search path, it will be loaded and the observer initialised. If we can't find the library, we will simply continue without the test observer.
2 participants
Use delayed dynamic linking for registering the test observer. This is particularly important for Windows which does not support weak linking and weak symbols. Even in the case that
Dependenciesis imported due to use, we will not pull in the test observer until runtime, as a best effort. If the DependenciesTestObserver library is found in the search path, it will be loaded and the observer initialised. If we can't find the library, we will simply continue without the test observer.