fork: surface HYDRA_BUILD_TYPE in --version (hydra_vortex #349)

[ddvnguyen]

Tracks ddvnguyen/hydra_vortex#349.

What

The static llama-server build (default per DevelopmentRunBook.md) hangs in the post-init phase on RTX sm_120 — see ddvnguyen/hydra_vortex#346. The fix is to use -DBUILD_SHARED_LIBS=ON, but the difference was invisible in CI: two builds of the same source with different BUILD_SHARED_LIBS produce different md5s but the same --version output.

This surfaces the build type in llama-server --version:

$ llama-server --version
version: 9549 (6e397fb32) [shared]
built with GNU 15.2.0 for Linux x86_64

Auto-derives from BUILD_SHARED_LIBS unless -DLLAMA_HYDRA_BUILD_TYPE=… is set explicitly (used by abi-benchmark/air-gap bundles with custom labels).

Files changed

• CMakeLists.txt: auto-derive LLAMA_HYDRA_BUILD_TYPE from BUILD_SHARED_LIBS (overridable via -DLLAMA_HYDRA_BUILD_TYPE=…)
• common/CMakeLists.txt: no change (build-info template is unchanged)
• common/build-info.cpp.in: add LLAMA_HYDRA_BUILD_TYPE macro + llama_hydra_build_type() accessor; append [type] to llama_build_info(); include in llama_print_build_info()
• common/build-info.h: declare llama_hydra_build_type()
• common/arg.cpp: include [type] in the --version output (line 1091)
• common/common.cpp: include [type] in the TRACE-level build log (line 382)

Test plan

• Shared build (build_sm120_v3, -DBUILD_SHARED_LIBS=ON) reports [shared]
• Static build (build_sm120_static, -DBUILD_SHARED_LIBS=OFF) reports [static]
• Override build (build_sm120_override, -DLLAMA_HYDRA_BUILD_TYPE=experimental) reports [experimental]
• P100 shared build (build_sm60_v2) reports [shared]
• CI smoke test in ddvnguyen/hydra_vortex (parent repo) refuses static deploys

Cross-repo links

• Hydra parent issue: [Llama-Engine-P2] Tag llama-server builds with build-type metadata (static vs shared) so the OCI image self-identifies hydra_vortex#349
• Hydra parent PR: feat: [Llama-Engine-P2-349] tag llama-server builds with build_type (shared|static) + CI gate hydra_vortex#351 (open)
• Parent submodule bump: deferred to a follow-up commit after this fork PR merges, per the standard 08-llama-fork.md push-before-PR rule

Risks

• The --version output format changes (now includes [shared] / [static]). Any tooling that parses the version line with a strict regex needs to be updated. The downstream consumer scripts/ci/check-build-type.sh is updated in the parent PR to match.
• The build_info() string gains a trailing [type] token. Any user that grep'd the string for a SHA match should be fine; the SHA is unchanged in position.
• The TRACE-level build log in common_params_print_info now includes [type] — only visible at -lv 4 and above, no impact on default verbosity.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

[ddvnguyen]

Review — surface build-type in --version (ggml-org#349)

Clean, well-scoped fork change, and the round-2 cache fix is the right one. A couple of confirmations, no blockers.

The cache fix is correct

Caching the override (LLAMA_HYDRA_BUILD_TYPE_OVERRIDE, empty by default) and recomputing the derived LLAMA_HYDRA_BUILD_TYPE as a normal variable each configure is the correct way to avoid the stale-[shared]-on-reconfigure bug. Good.

One thing to confirm (the fix depends on it)

The whole cache fix rests on common/build-info.cpp.in being re-substituted via configure_file() at configure time, where LLAMA_HYDRA_BUILD_TYPE is in scope. Upstream llama.cpp generates build-info two different ways depending on version — a configure-time configure_file, or a build-time custom command running common/cmake/build-info-gen-cpp.cmake, which only passes LLAMA_BUILD_NUMBER/COMMIT/COMPILER/TARGET. If this fork uses the build-time-script path, @LLAMA_HYDRA_BUILD_TYPE@ would expand to empty (or fail to update on reconfigure) unless the script is also passed the new var. Your test plan shows [shared]/[static]/[experimental] all reporting correctly on fresh dirs, so the substitution works — but please confirm it also updates on an in-place reconfigure of the same build dir (cmake -B X -DBUILD_SHARED_LIBS=OFF over a dir previously built =ON), since that reconfigure case is exactly what round 2 was about. If build-info is build-time-generated, the gate could still see a stale label.

Minor

• --version format changes to ... (sha) [type]. You've flagged downstream parsers; the one in-tree consumer (check-build-type.sh) greps the bracket form, and you kept the bracket form consistent across llama_build_info() / llama_print_build_info() / the TRACE log — good, all sinks share one regex.

LGTM pending the in-place-reconfigure confirmation. Merge-order note: parent ggml-org#351's deploy gate depends on this landing on hydra-fork first (see my review there).

---

Generated by Claude Code

[ddvnguyen]

Re-review — open item resolved, LGTM ✅ (comment; GitHub blocks self-approval)

No new commits since my first pass (head 746e585, 2 commits). My one outstanding question was whether the round-2 cache fix actually takes effect on an in-place reconfigure — i.e. whether build-info.cpp.in is re-substituted at configure time or baked by a build-time generator script that wouldn't see LLAMA_HYDRA_BUILD_TYPE. I checked the fork's common/CMakeLists.txt directly:

set(TEMPLATE_FILE "${CMAKE_CURRENT_SOURCE_DIR}/build-info.cpp.in")
set(OUTPUT_FILE   "${CMAKE_CURRENT_BINARY_DIR}/build-info.cpp")
configure_file(${TEMPLATE_FILE} ${OUTPUT_FILE})   # line 39 — configure-time

It's a configure-time configure_file(), not a build-time script. So the chain is sound by construction:

• LLAMA_HYDRA_BUILD_TYPE is a normal (non-cache) variable set in the top-level CMakeLists.txt before add_subdirectory(common), so it's in scope here and inherited into the subdirectory.
• Every reconfigure re-derives it from the BUILD_SHARED_LIBS cache value (or the override) and re-runs configure_file, regenerating build-info.cpp with the fresh label.
• Caching the override (empty by default) rather than the derived label is exactly what prevents a stale [shared] surviving a =ON → =OFF reconfigure.

That matches the author's documented test (-DBUILD_SHARED_LIBS=ON then =OFF → re-derives to static). The cache fix is correct, and the #351 gate it feeds can't be silently bypassed by a reused build dir.

The other earlier points are all fine: the [bracket] label form is consistent across --version / llama_build_info() / llama_print_build_info() / the TRACE log (one regex matches all sinks), and the --version format change is documented for downstream parsers (check-build-type.sh greps the bracket).

LGTM for hydra-fork. (Parent ggml-org#349/ggml-org#351's deploy gate depends on this landing first — and note ggml-org#354 already merged #13 onto hydra-fork, so when this merges, double-check the parent submodule bump for ggml-org#351 lands a hydra-fork commit that contains both.)

---

Generated by Claude Code