I'm not entirely sure what you think is fragile about executable_path()? We're already using it elsewhere in the tests.
If you're concerned about the ../lib/ relative path, then; whoops! Now uses mtf::library_path().
I much prefer the current solution to using dladdr() in the release code. Using dladdr() we make some assumptions about the code that the compiler emits and if those assumptions fail then our release code fails. If the assumptions we set MIR_CLIENT_PLATFORM_PATH based on fail then at worst our test suite fails.
Regardless of how we find the platform libraries by default we'll want a MIR_CLIENT_PLATFORM_PATH option for roughly the same reasons that we have a MIR_CLIENT_PLATFORM_LIB option.
I'm not entirely sure what you think is fragile about executable_path()? We're already using it elsewhere in the tests.
If you're concerned about the ../lib/ relative path, then; whoops! Now uses mtf::library_ path().
I much prefer the current solution to using dladdr() in the release code. Using dladdr() we make some assumptions about the code that the compiler emits and if those assumptions fail then our release code fails. If the assumptions we set MIR_CLIENT_ PLATFORM_ PATH based on fail then at worst our test suite fails.
Regardless of how we find the platform libraries by default we'll want a MIR_CLIENT_ PLATFORM_ PATH option for roughly the same reasons that we have a MIR_CLIENT_ PLATFORM_ LIB option.