feat(json-c): add json-c/json-c formula

[fennoai]

Closes #39.

Translates the Conan Center json-c recipe (snapshot ffe30df101afd4dc95aac2f14b25bf345e64d7be, version 0.18) into an idiomatic LLAR Formula.

Module

• json-c/json-c/versions.json — path json-c/json-c, no dependency fallbacks (json-c has none).
• json-c/json-c/json-c-0.18-20240915/Jsonc_llar.gox — fromVer "json-c-0.18-20240915", the exact upstream tag Conan records for 0.18.

Translation notes

• No dependencies. The Conan recipe declares no requirements/tool_requires/test_requires, and the upstream 0.18 source confirms json-c is self-contained, so there is no onRequire and deps is empty.
• Build (CMake). Uses the LLAR CMake helper with the library-only configuration the Conan recipe applies for >= 0.17: BUILD_STATIC_LIBS=ON/BUILD_SHARED_LIBS=OFF (Conan default shared=False), DISABLE_STATIC_FPIC=OFF (Conan default fPIC=True), BUILD_TESTING=OFF, BUILD_APPS=OFF. CMAKE_INSTALL_LIBDIR=lib normalizes the layout so the installed json-c.pc and the dependency search paths resolve without lib64 handling.
• Metadata. Derived from the installed json-c.pc via pkg-config --cflags --libs --static json-c, so the consumer flags include the private -lm json-c uses on UNIX — matching the Conan package_info (system_libs = ["m"] on Linux/FreeBSD for >= 0.17).
• Test. onTest mirrors the Conan test_package: it writes a small consumer that includes <json-c/json.h>, links the installed json-c::json-c CMake target, builds it in a tree separate from the onBuild scratch tree, and runs it. This keeps the test valid on a cache hit (where onBuild is skipped).
• fromVer boundary. Only the exact 0.18 tag is claimed as verified per the issue's instruction; no unverified version range is asserted.

Validation

Built and installed with the local goplus/llar CLI (installed exactly as CI does). All passing (exit 0):

• llar test -v ./json-c/json-c@json-c-0.18-20240915 — fresh build + consumer run.
• Re-run of the same selection — cache-hit onTest (onBuild skipped) still passes.
• llar test ./json-c/json-c@json-c-0.18-20240915 --os linux --arch amd64 — explicit host matrix.
• llar test --verbose ./json-c/json-c --os linux --arch amd64 — the exact CI command; resolves to the latest tag (json-c-0.19-20260627), which fromVer also serves, and builds/tests cleanly.

The installed tree contains lib/libjson-c.a, include/json-c/*.h, lib/pkgconfig/json-c.pc, and lib/cmake/json-c/, and the consumer prints { "Categories": [ "c", "c++" ] }.

Note on options. The Conan recipe exposes shared/fPIC options. I did not model them as Formula target.options because the currently-released goplus/llar build phase does not apply requested --option values to the module instance that runs onBuild/onTest (internal/modules/convertToModules builds the formula without injectMatrix), so a non-default --option selection is silently ignored and always falls back to the Formula defaults. Exposing options that cannot be honored would be misleading, so this Formula builds the Conan default (static + fPIC) directly. Once llar threads options into the build phase, shared/fPIC can be added as target.options in a follow-up.

[fennoai]

FennoAI Review — json-c/json-c Formula

Overall this is a well-structured Formula that follows the LLAR conventions closely: id, versions.json.path, and the directory json-c/json-c all agree; the filename stem Jsonc is a valid Go identifier; fromVer is a non-empty string literal aligned with the directory; c.configure/c.build/c.install are called without result assignment or ! as required; os.mkdirAll/os.writeFile use the ! failure form; and the capout + lastErr + ctx.setMetadata metadata block matches the reference. The cmake defines and the -lm/pkg-config comments were verified accurate against the json-c-0.18-20240915 source (json-c.pc.in Libs.private: @LIBS@, upstream DISABLE_STATIC_FPIC branch). Performance and security passes found no issues.

Two low-severity findings on the onTest consumer block are left inline. Neither is a correctness bug; both are about the temp-checkout convention and comment accuracy.

Reviewers should still confirm BUILD_STATIC_LIBS, BUILD_APPS, and DISABLE_STATIC_FPIC exist in the CMake of this exact upstream tag, and that llar test passes after both a fresh build and a cache hit.

[fennoai]

onTest synthesizes consumer.c and CMakeLists.txt and writes them into ctx.SourceDir (testDir := ctx.SourceDir + "/_llar_consumer"), mutating the temporary upstream checkout. The reference's "Installed-Output Tests" section says test source files should come from the fresh ctx.SourceDir checkout or from files shipped in the Formula module (read via ctx.Proj.readFile); the example treats ctx.SourceDir + "/consumer" as a pre-existing subdir, not a place to generate files. Consider shipping consumer.c/CMakeLists.txt in the Formula module (read with ctx.Proj.readFile) or writing them to a scratch dir outside the source checkout.

Also, the comment's stated reason is inaccurate: the separate tree is not what makes the test "run on a cache hit." On a cache hit LLAR creates a fresh ctx.SourceDir and runs onTest against the persisted ctx.outputDir, so onBuild's _build never exists there regardless. A build tree separate from _build is the right convention, but its real purpose is avoiding collision with onBuild's tree during a cache-miss build-then-test run — not enabling cache-hit tests. Suggest rewording to attribute it to that (or to convention).