Problem
The Core ML CMake target links portable_ops_lib and portable_kernels privately when the standalone runner option is enabled. The standalone Xcode runner already links those archives itself, while other Core ML consumers should not pull in a second operator registry.
A proposed switch from link edges to build dependencies surfaced another requirement: add_dependencies fails when portable operators are disabled unless both targets are guarded. This was found during the source-build validation for #22620 and is intentionally excluded from that documentation-only PR.
Proposed change
Use build-order dependencies instead of private linkage where appropriate, guarded with TARGET portable_ops_lib and TARGET portable_kernels.
Test plan
- Configure the macOS preset with Core ML enabled and portable operators disabled.
- Build the Core ML runner configuration with portable operators enabled.
- Run Core ML model and operator CI.
cc @larryliu0820 @GregoryComer @kimishpatel @YifanShenSZ @cymbalrush @metascroy
Problem
The Core ML CMake target links
portable_ops_libandportable_kernelsprivately when the standalone runner option is enabled. The standalone Xcode runner already links those archives itself, while other Core ML consumers should not pull in a second operator registry.A proposed switch from link edges to build dependencies surfaced another requirement:
add_dependenciesfails when portable operators are disabled unless both targets are guarded. This was found during the source-build validation for #22620 and is intentionally excluded from that documentation-only PR.Proposed change
Use build-order dependencies instead of private linkage where appropriate, guarded with
TARGET portable_ops_libandTARGET portable_kernels.Test plan
cc @larryliu0820 @GregoryComer @kimishpatel @YifanShenSZ @cymbalrush @metascroy