Keep build-machine paths out of the Linux RUNPATH

[takusaito-ctrl]

Fixes #52. Stacked on #51 — base is fix/linux-opencv-mcpb-bundling, so this diff is just the CMake change. Retarget to main once #51 merges.

The bug

api/server/CMakeLists.txt already asked for $ORIGIN, but CMake prepends it to the automatic build-tree RPATH instead of replacing it. Because the target links libCr_Core.so and the OpenCV libs by absolute path, their source-tree directories were appended — and shipped inside the binary, into the .mcpb:

RUNPATH: [$ORIGIN:/home/<user>/Desktop/Github/alpha-sdk-api/shared/sdk/lib:
                  /home/<user>/Desktop/Github/alpha-sdk-api/shared/opencv/Linux:]

Those entries were pure redundancy: POST_BUILD (lines 153-163) already copies every runtime lib next to the executable, so $ORIGIN alone resolves everything in both the build tree and the bundle.

Their only real effect was harmful — they let the loader fall back to the build machine's checkout. That is exactly how #33 hid: the bundle shipped with no OpenCV at all, tested fine on the machine that built it, and failed with exit 127 everywhere else.

The change

BUILD_WITH_INSTALL_RPATH makes the build-tree link use INSTALL_RPATH directly and skips the automatic computation, leaving RUNPATH as just $ORIGIN.

macOS deliberately untouched. It likely has the same leak — BUILD_RPATH "@executable_path" gets the same augmentation and no INSTALL_RPATH is set — but there is no macOS hardware here to verify, and the CrAdapter layout there is delicate after 4e1927a. Noted in #52 as follow-up.

Test plan

linux-arm64 (Raspberry Pi), CMake 3.28.3, SDK V2.02.00.

• RUNPATH is now [$ORIGIN] — absolute paths gone
• Dev workflow unaffected — api/server/build/CameraWebApp resolves everything from build/, 0 unresolved
• Bundle portable by construction — extracted .mcpb shows [$ORIGIN] and 0 unresolved with no path rewriting needed (previously this required faking a clean machine)
• Missing libs now fail loudly — deleting the OpenCV libs from an extracted bundle produces exit 127 on the build machine. Before this change the same test silently succeeded by falling back to the source tree. This is the regression guard that would have caught Linux: OpenCV never bundled into .mcpb — opencvLibDir() paths cannot match what extract.ts writes #33 immediately.
• Live hardware, ILCE-1M2 over USB, via the bundled server: discovery → connect → live view 1024x680 → OSD composite 640x480 rendered correctly with full camera UI
• /proc/<pid>/maps confirms all three OpenCV libs mapped from the bundle, 0 libs resolved from the source tree
• Graceful shutdown released the camera cleanly in 4s

Tested on a different body (ILCE-1M2) than #51 (ILCE-7M5), so the pair covers two models.

Note: terminate called without an active exception at shutdown is pre-existing #42, unrelated.

[jordlee]

Heads-up: this PR is marked MERGED, but its change never reached main.

It was opened with fix/linux-opencv-mcpb-bundling (the #51 branch) as its base rather than main. I merged #51 into main first, then merged this one — which sent it into a branch that had already been merged and was no longer flowing anywhere. GitHub's MERGED state is accurate for what it did; main simply never received the commit.

My error: I checked mergeable, mergeStateStatus and CI on all three PRs before merging, but not baseRefName. Merging this one first, or retargeting it to main, would have avoided it.

Re-landed in #55 as a clean git cherry-pick 78654ee onto main — your commit, unmodified, authorship preserved. Confirmed on main: api/server/CMakeLists.txt now carries BUILD_WITH_INSTALL_RPATH TRUE on the elseif(UNIX) branch, and the macOS build is unaffected.

Worth being aware of the general shape: a stacked PR whose base gets merged first ends up MERGED with its change nowhere, and nothing in the UI flags it.