fix(build): make the app bundle self-contained instead of reaching into the source tree

[datlechin]

The root cause behind #2334. That PR restored Libs/ in the test jobs and asserted the two dylibs exist, which stops the symptom; this stops the app needing them from a source tree at all.

What was wrong

project.yml put $(SRCROOT)/Libs/dylibs on LD_RUNPATH_SEARCH_PATHS, which bakes an absolute path into the binary. TablePro.debug.dylib is the app's own code, loaded at launch, and it links @rpath/libssl.3.dylib and @rpath/libcrypto.3.dylib. Those are not copied into the bundle in a Debug build, so that absolute rpath was the only thing resolving them.

A Debug app therefore only ran from a checkout that happened to have Libs/dylibs on disk. When the sharded test jobs stopped downloading Libs, the host aborted with SIGABRT before XCTest could connect, reporting zero tests and naming neither the library nor the reason.

A release build was already self-contained: build-release.sh's bundle_dylibs() copies them in and rewrites the install names.

The fix

Both dylibs already carry an @rpath/ install name, set by create-openssl-dylibs.sh, so copying them into Contents/Frameworks is enough and no install_name_tool is needed. A copy-files phase does that, and @executable_path/../Frameworks was already first on the rpath list.

$(SRCROOT)/Libs/dylibs then comes off the app target's LD_RUNPATH_SEARCH_PATHS. LIBRARY_SEARCH_PATHS keeps it, because that is link time and legitimate.

Verified by building

Contents/Frameworks/   libcrypto.3.dylib  libssl.3.dylib

app rpaths:  @executable_path
             @loader_path
             <DerivedData>/Build/Products/Debug/PackageFrameworks
             @executable_path/../Frameworks

source-tree rpaths: 0

Then the scenario that failed in #2334: products tarred, unpacked into a different directory, and the full unit suite run against them.

Test run with 11666 tests in 1387 suites passed after 132 seconds

The host launches, no SIGABRT. The remaining absolute path is the DerivedData PackageFrameworks entry, which is normal for a Debug build and travels inside the products tarball.

Scope

The six plugin targets keep their $(SRCROOT)/Libs/dylibs rpath entry. A plugin loaded into the app resolves through the app's Contents/Frameworks anyway, so the entry is inert there, and I cannot verify a registry plugin installed outside the bundle from here. Removing those is cosmetic and belongs with someone who can test that path.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.