fix(build): disable LLAMA_BUILD_APP/UI so the CUDA/SYCL source build links - #43
Merged
Conversation
The b9837 submodule bump (#42) resolved the bridge API drift, but the from-source CUDA and SYCL release targets then failed at 3% with: app/llama.cpp:1:10: fatal error: build-info.h: No such file or directory b9837 introduced two new CMake targets — LLAMA_BUILD_APP (the "unified binary") and LLAMA_BUILD_UI — both defaulting ON for a standalone (top-level) build. build.rs disables TESTS/EXAMPLES/TOOLS/SERVER but not these, so cmake tried to build app/llama.cpp, which needs a generated build-info.h and breaks the library-only build we need for FFI. Pass -DLLAMA_BUILD_APP=OFF and -DLLAMA_BUILD_UI=OFF. Verified against a b9837 checkout: with these flags the app subdirectory is no longer configured and libllama/ggml/common build cleanly. Only affects the from-source backends (CUDA/SYCL); prebuilt targets (CPU/Vulkan/macOS) never run the cmake source build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adjusts the llama-sys from-source CMake configuration to prevent llama.cpp’s newly-added application/UI targets from being built when compiling CUDA/SYCL backends from source, ensuring the build only produces the libraries needed for FFI.
Changes:
- Disable llama.cpp’s
LLAMA_BUILD_APPtarget during from-source builds to avoid compilingapp/(and its generated-header dependency). - Disable
LLAMA_BUILD_UIduring from-source builds to avoid the embedded UI target behavior. - Add in-file rationale documenting why these options are explicitly turned off.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
Follow-up to #42. That PR fixed 3 of the 5 release targets and bumped the llama.cpp submodule to
b9837, which resolved the bridge API drift on the two from-source targets (CUDA, SYCL). But those two then failed at a new point —v0.17.3Release run 28913925408:Root cause
b9837introduced two new CMake options that both default ON for a standalone (top-level) build:build.rsdisablesTESTS/EXAMPLES/TOOLS/SERVERbut not these newer targets, so cmake built theapp/llama-appbinary — which#includes a generatedbuild-info.hit can't find. We only need the libraries (libllama,libggml*,libcommon) for FFI, so theappbinary should never be built.Prebuilt targets (CPU/Vulkan/macOS) are unaffected — they download
.sos and never run the cmake source build. This only bit the two from-source backends.Fix
Add
-DLLAMA_BUILD_APP=OFF -DLLAMA_BUILD_UI=OFFto the cmake configure inbuild_from_source. Older llama.cpp releases that lack these options ignore the flags harmlessly.Verification
Reproduced and validated locally against a
b9837checkout with the exactbuild.rsflags:appsubdir added?mainflags (noLLAMA_BUILD_APP)-DLLAMA_BUILD_APP=OFFllama,ggml,ggml-base,commontargets still present.libllama.abuilds cleanly past the point where CI failed.CI note: the Release matrix only runs on a
v*tag, so this won't be exercised by this PR's checks — it needs a tag (or aworkflow_dispatchtrigger) to confirm green end-to-end.