One nlohmann/json, and the open items brought up to date

[bernardladenthin]

The FetchContent for nlohmann/json is gone

There never was a compile that used it. llama.cpp carries its own copy at vendor/nlohmann/ and
exports that directory through the vendor::nlohmann INTERFACE target, which common/CMakeLists.txt
links PUBLIC into llama-common — and that directory comes before a FetchContent include dir on
every jllama compile line. Measured at the b11556 bump in flags.make: vendor/nlohmann/.. was
-I number 7, json-src/include number 12.

So the two project headers that include nlohmann/json.hpp always resolved to upstream's copy, exactly
as every upstream TU does.

Keeping it that way is the point: one copy in every translation unit. Two copies of the same
classes with different layouts in one link is the httplib incident — the linker's choice per platform
decided the behaviour, and it differed per platform.

What made the duplicate indefensible rather than merely idle: since b11556 upstream applies
vendor/nlohmann/json-deep-nesting.patch to its copy, so the fetched v3.12.0 was not even the same
code. It cost a clone per fresh build directory, two link entries, and a pinned tag that looked like
something to keep in sync with a library this project does not choose the version of.

A configure-time guard replaces it

Beside the aligned-free check. Asserted rather than left to the compiler: a missing header fails every
TU with a message about the header, while this one names the expected location, says what to do —
and says explicitly what not to do, namely re-add a FetchContent, which would put a second,
differently-patched copy back on the path. The case it catches is a future upstream move of
vendor/nlohmann/.

Verification, and its limit

Confirmed at the exact pinned tag b11558:

link in the chain	evidence
the header exists	vendor/nlohmann/json.hpp → HTTP 200
the vendor root is exported	target_include_directories(nlohmann INTERFACE ..), with upstream's own comment "so consumers can include via <nlohmann/json.hpp>"
it reaches jllama	common/CMakeLists.txt:137 links vendor::nlohmann PUBLIC into llama-common (TARGET is llama-common from line 54)

No local compile. This build tree is from b11556 while the pin is b11558, so a reconfigure stops at
the patch applier's own "configure into a fresh build directory" refusal. The failure mode is loud on
every platform, and the guard turns it into a configure error — but CI is the proof, not this PR.

TODO.md brought up to date

Three statements had been overtaken:

	was	is
the header	"as of 2026-10-11, partly proven"	two consecutive green dispatch runs on main, through package, all six smokes and the publish chain
the cuda13 item	"Mitigated"	verified on the same hardware — same AMI, driver and T4; three exit 134 aborts became three clean runs
the openvino item	172× slower	336×

Three things added

1. The four defects in the published artefact set. Found by comparing the first green snapshot
against natives.csv and against Central — Central was correct, the GitHub release was not: no
*.pom at all (so llama-platform was absent entirely), unsigned AARs, a signature check that globbed
*.jar only, and 208 accumulated assets. Fixed in #529/#531 and verified on the live release
afterwards: 208 → 98 assets, 49 artefacts with 49 signatures, 23 of 23 natives jars,
llama-platform present. With the note that item 4 still applies to the three sibling repos, where
those two jobs are shared.

2. A prepared plan for the four upstream issues that have no patch to offer — title, the evidence to
paste and the question for the maintainers, one row each. With the rule for the day: state the
measurement and ask, do not propose a fix in code this project does not own.

3. Waiting on sccache. 0.18.0 is the newest release, and the -Xclang refusal is tracked in four
open issues — #1122 is the structural one. The cost is measured: 719 of 720 requests
non-cacheable on the Windows clang job, and every HIP TU refused on the ROCm job, which is the
critical path at 2:40–3:08 h against about an hour for the rest of a run combined. A re-check trigger
(the next sccache release, read the hit table in the job summary) rather than a schedule.

Verification

check-natives.py 0 disagreements, check-patches.py 12 patches / 99 hunks clean, 122 buildcheck
tests green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01E2h8gXyyE5UeimkL9vQv9G

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud