Describe the bug
The recently added --target universal-apple-darwin pseudo-target produces a binary which contains the target triple in its file name. This build info isn't accessible for an application at runtime, resulting in a failure to locate the binary at runtime.
Reproduction
- Try running or building the sidecar example with
--target universal-apple-darwin.
Expected behavior
1. Omit target triple from bundled binary file names
Simply remove the target triple while copying the binary. This means that the user-facing contract remains consistent, so users would simply create a universal binary prior to build and name it my-sidecar-universal-apple-darwin. At dev/build time, it would be renamed to my-sidecar.
2. Include the target triple with the main executable
We could keep naming the same, and instead include the target triple as a constant - instead of inferring it at runtime.
My thoughts
I am in favor of 1, because it's consistent with the main executable and simplifies runtime logic.
However, note that there is one restriction: using the universal target requires the user to create a universal binary also for sidecar, prior to the build. It is not possible to mix and match, and it would be hard to do so in the future without exposing more complicated knobs/flags etc to the user. I think this is ok, simple, and expected.
However, we need to instruct users on how to build universal sidecar binaries themselves, which is very simple on MacOS (and in the future, it's likely lipo or equivalent will be available across platforms).
Platform and versions
Stack trace
No response
Additional context
Caveat: possibly breaking change
The proposed change would affect both the CLI and the runtime, so users would have to upgrade both in lockstep. This could constitute a breaking change if users upgrade these separately. Please let me know if we need considerations for that case.
PR coming
I already fixed this in my fork and will send out a PR with the changes.
Describe the bug
The recently added
--target universal-apple-darwinpseudo-target produces a binary which contains the target triple in its file name. This build info isn't accessible for an application at runtime, resulting in a failure to locate the binary at runtime.Reproduction
--target universal-apple-darwin.Expected behavior
1. Omit target triple from bundled binary file names
Simply remove the target triple while copying the binary. This means that the user-facing contract remains consistent, so users would simply create a universal binary prior to build and name it
my-sidecar-universal-apple-darwin. At dev/build time, it would be renamed tomy-sidecar.2. Include the target triple with the main executable
We could keep naming the same, and instead include the target triple as a constant - instead of inferring it at runtime.
My thoughts
I am in favor of 1, because it's consistent with the main executable and simplifies runtime logic.
However, note that there is one restriction: using the universal target requires the user to create a universal binary also for sidecar, prior to the build. It is not possible to mix and match, and it would be hard to do so in the future without exposing more complicated knobs/flags etc to the user. I think this is ok, simple, and expected.
However, we need to instruct users on how to build universal sidecar binaries themselves, which is very simple on MacOS (and in the future, it's likely
lipoor equivalent will be available across platforms).Platform and versions
Stack trace
No response
Additional context
Caveat: possibly breaking change
The proposed change would affect both the CLI and the runtime, so users would have to upgrade both in lockstep. This could constitute a breaking change if users upgrade these separately. Please let me know if we need considerations for that case.
PR coming
I already fixed this in my fork and will send out a PR with the changes.