Rename executorch cmake target to prim_ops_lib

[TejasweeSulekh]

Summary

This PR renames the confusing executorch CMake target to prim_ops_lib. This change clearly reflects its purpose as the Primitive Operations Library and brings it in line with the naming convention of portable_ops_lib.

Key Changes

• Renamed the core executorch target definition in CMakeLists.txt to prim_ops_lib, alongside its source file arrays (_prim_ops_lib__srcs and PRIM_OPS_LIB_SRCS).
• Maintained Backwards Compatibility:
  • Created an INTERFACE CMake target named executorch that proxies to prim_ops_lib. Downstream consumers calling target_link_libraries(myapp executorch) will not break.
  • Used set_target_properties(... OUTPUT_NAME "executorch") to ensure the compiled archive is still named libexecutorch.a. This prevents breakages in the dozens of internal CI shell scripts and iOS Xcode .pbxproj configurations that explicitly look for that file.
• Updated internal library usages (Backends, Llama, Muse-Glimmer, Devtools, Docs) to reference prim_ops_lib.
• Fixed a regression where primitive operators were stripped from LLaMA by properly restoring executorch_target_link_options_shared_lib(prim_ops_lib) to its CMake file.

Fixes #11761

Test plan

Configured, built, and executed a model at runtime to guarantee no primitive operator symbols were stripped by the linker.

# Clean and Configure
source .venv/bin/activate
rm -rf cmake-out
cmake -B cmake-out .

# Build to guarantee linkage succeeds
cmake --build cmake-out -j$(nproc)

# Runtime verification (Generated a dummy add.pte model locally to prove aten::sym_size and other prim ops weren't stripped)
./cmake-out/executor_runner --model_path /tmp/add.pte
# Outputs: OutputX 0: tensor(sizes=[1], [2.])

cc @nil-is-all

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/23177

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 4 New Failures, 2 Pending, 1 Unrelated Failure, 7 Unclassified Failures

As of commit 0059406 with merge base f55681f ():

NEW FAILURES - The following jobs have failed:

• Cadence Build & Test / Resolve CI docker image / resolve (gh)
  ##[error]Refusing to check out fork pull request code from a 'pull_request_target' workflow. This workflow runs with the base repository's GITHUB_TOKEN, secrets, default-branch cache scope, and runner access. Fetching and executing a fork's code in that trusted context commonly leads to "pwn request" vulnerabilities. To opt in, review the risks at https://gh.io/securely-using-pull_request_target and set 'allow-unsafe-pr-checkout: true' on the actions/checkout step.
• pull / android / build-android (gh)
• pull / test-voxtral-realtime-xnnpack-linux / linux-job (gh)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 2
• pull / test-vulkan-models-linux / linux-job (gh)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 1

UNCLASSIFIED FAILURES - DrCI could not classify the following jobs because the workflow did not run on the merge base. The failures may be pre-existing on trunk or introduced by this PR:

• MLX / test-mlx-muse-glimmer-build / test-mlx-muse-glimmer-build (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Command bash /Users/runner/work/_temp/exec_script failed with exit code 2
• MLX / test-mlx-qwen35-moe / test-mlx-qwen35-moe (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Command bash /Users/runner/work/_temp/exec_script failed with exit code 2
• MLX / test-mlx-supertonic / test-mlx-supertonic (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Command bash /Users/runner/work/_temp/exec_script failed with exit code 2
• Test CUDA Builds / test-muse-glimmer-cuda-e2e-kquant-17gb-dflash-image / linux-job (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 2
• Test CUDA Builds / test-muse-glimmer-cuda-e2e-kquant-17gb-solo-text / linux-job (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 2
• Test CUDA Builds / test-muse-glimmer-cuda-e2e-kquant-dynamic-dflash-image / linux-job (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 2
• Test CUDA Builds / test-muse-glimmer-cuda-e2e-kquant-dynamic-solo-text / linux-job (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 2

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• pull / test-arm-backend-no-driver (test_pytest_models_tosa) / linux-job (gh) (trunk failure)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 1

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[metascroy]

@claude review this code. Does _executorch__srcs (which defined the old executorch library) really only contain primp op sources? If so, should _executorch__srcs be renamed?

[metascroy]

cc @JacobSzwejbka for core runtime

[claude]

Claude finished @metascroy's task in 2m 5s —— View job

---

Review: Rename executorch CMake target to prim_ops_lib

• Gather diff and context
• Check what _executorch__srcs contains
• Review downstream usages / config changes
• Post review

---

Answer: does _executorch__srcs contain only prim op sources?

Yes. _executorch__srcs gets filled from EXECUTORCH_SRCS in shim_et/xplat/executorch/build/build_variables.bzl (the mapping is in tools/cmake/Codegen.cmake:564-626). That list has three files:

EXECUTORCH_SRCS = [
    "kernels/prim_ops/et_copy_index.cpp",
    "kernels/prim_ops/et_view.cpp",
    "kernels/prim_ops/register_prim_ops.cpp",
]

Program, Method, the platform code and the rest of the runtime all sit in EXECUTORCH_CORE_SRCS / executorch_core. So the comment above the target (CMakeLists.txt:703-709, "executorch: Primary runtime library… Provides the Program and Method interfaces") is out of date. The target only compiles prim ops and pulls executorch_core in transitively through its PRIVATE link.

Should it be renamed? Yes. The file lists follow a _<target>__srcs convention (_executorch_core__srcs, _portable_kernels__srcs, …). With this PR, _executorch__srcs would be the only one that doesn't match its target's name. I suggest renaming EXECUTORCH_SRCS to PRIM_OPS_LIB_SRCS in build_variables.bzl and _executorch__srcs to _prim_ops_lib__srcs in Codegen.cmake, and rewriting the comment at CMakeLists.txt:703-709. No Buck targets.bzl loads EXECUTORCH_SRCS, so the only other user is Codegen.cmake.

Fix this →

---

Blocking issues

1. The rename is incomplete, and configure fails in several builds. No alias is kept, so every remaining executorch link item turns into a plain -lexecutorch that no longer resolves. With CMake's usual behaviour, a missing target like this shows up at link time, not configure time. That is why cmake -B cmake-out . in the test plan passed. References that still use the old name include:

• examples/portable/custom_ops/CMakeLists.txt:113: gen_operators_lib(... DEPS executorch). This file is in the PR, but only line 109 was changed.
• examples/models/llama/CMakeLists.txt:91: set(link_libraries executorch gflags). Also in the PR.
• examples/models/muse-glimmer/CMakeLists.txt:36: set(link_libraries executorch gflags). Also in the PR.
• test/CMakeLists.txt:56 (size_test), kernels/prim_ops/test/CMakeLists.txt:23, extension/llm/runner/test/CMakeLists.txt:70, extension/training/CMakeLists.txt:60.
• backends/arm/cmake/ArmRunnerUtilsInternal.cmake:559,561, examples/qualcomm/CMakeLists.txt:70, backends/mlx/examples/llm/CMakeLists.txt:38, examples/llm_server/cpp/CMakeLists.txt:37.
• Almost every examples/models/*/CMakeLists.txt (whisper, gemma3/4, voxtral*, parakeet, llava, dinov2, sortformer, silero_vad, qwen3_5_moe, …).
• Multi-line target_link_libraries blocks in zephyr/, extension/android/CMakeLists.txt, examples/arm/*, examples/mediatek, examples/devtools, examples/nxp/..., backends/cadence/CMakeLists.txt, backends/cadence/hifi/operators/tests.

2. The installed archive changes from libexecutorch.a to libprim_ops_lib.a, which breaks scripts that ask for it by file name. For example, scripts/build_apple_frameworks.sh:28 lists libexecutorch.a when it assembles the iOS frameworks. It also turns up in test/build_size_test.sh, .ci/scripts/utils.sh, .ci/scripts/test_llama.sh, examples/apple/coreml/scripts/build_executor_runner.sh, backends/apple/coreml/scripts/build_tests.sh, the CoreML .xcodeproj files, and the docs (using-executorch-ios.md, using-executorch-building-from-source.md, backends-qualcomm.md, .claude/skills/building/SKILL.md).

3. The PR description doesn't match the diff, and the llama change is a regression. The description says executorch_target_link_options_shared_lib(prim_ops_lib) was added to tools/cmake/executorch-config.cmake, but that file's only change is swapping the name in required_lib_list (line 61). Even so, examples/models/llama/CMakeLists.txt drops its executorch_target_link_options_shared_lib(executorch) call. The llama runner would then link prim ops without whole-archive. register_prim_ops.cpp registers through a static initializer, so the linker can drop it, and prim ops such as aten::sym_size fail at runtime with "operator not found". Either add the call to the config file as described, or keep it in llama and rename the target there.

4. Downstream users break. executorch is a documented, installed target that external projects link against directly. Renaming it without a transition path breaks all of them. I'd recommend keeping a compatibility target for at least one release:

add_library(executorch INTERFACE)
target_link_libraries(executorch INTERFACE prim_ops_lib)

Both targets would also need to be in the install(TARGETS …) export set, or the equivalent ALIAS/imported target set up in executorch-config.cmake. The PR should also get a release notes: label that points out the rename.

Minor

• CMakeLists.txt:704: the comment header still reads # executorch:.
• docs/source/kernel-library-custom-aten-kernel.md:172: the inline comment still says "executorch is a dependency of it".
• tools/cmake/executorch-config.cmake:41-48: the comment still talks about libexecutorch.a.

Suggested test plan

The configure-only run in the PR can't catch these problems. At minimum, run a full build plus a model run through executor_runner and llama_main, for example cmake --preset llm && cmake --build cmake-out -j && ./cmake-out/executor_runner --model_path add.pte. That exercises prim-op registration. Also run scripts/build_apple_frameworks.sh if you have access to macOS.

[TejasweeSulekh]

Thanks for the thorough review, and my bad I completely missed the downstream linking impacts and hardcoded script names.

I'll push an update tomorrow to fix the broken references and add the INTERFACE compatibility target so we don't break existing users.

[TejasweeSulekh]

@pytorchbot label "release notes: build"

[TejasweeSulekh]

Hey @nil-is-all, I've pushed a new commit which is addressing the feedback provided above. Which are as follows:

• Incomplete Variable Renames: I've updated Codegen.cmake and build_variables.bzl so that _prim_ops_lib__srcs and PRIM_OPS_LIB_SRCS now perfectly match the new target name
• Backwards Compatibility & Downstream Breakages: I added an INTERFACE CMake alias for executorch that proxies directly to prim_ops_lib. Downstream integrations won't break
• Broken CI Scripts & libexecutorch.a: I used set_target_properties(prim_ops_lib PROPERTIES OUTPUT_NAME "executorch"). This keeps the compiled archive named libexecutorch.a, guaranteeing that the iOS Xcode projects and internal CI shell scripts remain completely untouched and functional
• LLaMA Regression: This was a mishap on my end for missing this one. I've correctly restored executorch_target_link_options_shared_lib(prim_ops_lib) in the LLaMA CMake config.
• Documentation Update: Cleaned up the outdated comment in docs/source/kernel-library-custom-aten-kernel.md and the header in CMakeLists.txt

Just to confirm this is working correctly, I ended up executing a dummy .pte model through executor_runner locally to guarantee the runtime ops aren't being stripped.

I also took the liberty to update the main description of the PR to be more aligned to the final changes.