fix: stop Tailwind oxide scanner from inheriting AUR .gitignore

[zoitrok]

PR #8 moved the npm build into build() so cmake's execute_process wouldn't run it. That avoided the cmake subprocess but didn't change what npm produces - bundle.css is still ~404 KB with zero Tailwind utility classes.

Root cause

Tailwind v4's @tailwindcss/oxide uses Rust's ignore crate, which walks up to the nearest .git and applies that repo's .gitignore. Under yay/paru, that's the AUR clone - whose .gitignore is * + an allowlist for PKGBUILD/.SRCINFO. The * rule ignores tools/ui/src/lib/**/*.svelte, oxide scans 0 files, Tailwind emits 0 utility classes.

Fix

mkdir -p "${_pkgname}/.git" in prepare(). An empty .git halts the upward walk at the llama.cpp tree root, before it reaches the AUR clone.
A/B (same $srcdir, only difference is the .git boundary)

	bundle.css	.flex{
Before	404,432 B	0
After	505,965 B	1

505,965 B is also the size of the Hugging Face prebuilt for this version.

Notes

cmake/build-info.cmake runs git rev-parse from the source tree. An empty .git makes it fail with "not a git repository" - same as no .git at all (the tarball default). BUILD_COMMIT / BUILD_NUMBER defaults unchanged; PKGBUILD's -DLLAMA_BUILD_NUMBER already overrides anyway.
Verified end-to-end via makepkg -o + npm run build in ~/.cache/yay/llama.cpp-vulkan/.

[Orion-zhen]

I'm wondering if PR#8 and this PR are necessary. I commented npm, npm build and -DLLAMA_BUILD_WEBUI commands and build it locally. The webui worked well. Could you please try the current version on AUR to see if the webui works?

[zoitrok]

Just tested and built llama.cpp-vulkan b9222-2 from AUR, which still ends up with the broken bundle (attached screenshot).

Since upstream #22937 the webui is no longer bundled in the release tarball, but tools/ui/CMakeLists.txt + scripts/ui-download.cmake define three asset sources, picked in priority order:

1. Local pre-built - files already present in build/tools/ui/dist/. If a PKGBUILD or CI pre-populated them, cmake embeds them verbatim and skips everything below.
2. Local npm build - npm ci && npm run build via execute_process in tools/ui. Intended for webui developers (fast iteration) and packagers willing to ship a JS toolchain.
3. HF Bucket download - huggingface.co/buckets/ggml-org/llama-ui/resolve/b/…. Intended for packagers without npm and for offline-ish CI.

If npm is in PATH, (2) always wins over (3); HF is reached only when npm is missing or exits non-zero.

This PR sits in the gap between (2) and (3): the success check is npm exit == 0 && all 4 files exist, not content validity. The .gitignore-inheritance bug makes npm exit 0 while emitting a utility-empty bundle.css, so cmake - and PR #8's pre-build - latch onto the bad output and never escalate to (3). The boundary fix preserves path (2) instead of forcing everyone onto (3).

[Orion-zhen]

So that's quite weird then, in my friend's and mine test build, no npm and webui arg one build successfully, only with PR#8 failed to generate correct webui. I'll try PR#8 with this PR to see if it works.

[zoitrok]

That makes sense. If one doesn't have npm & friends installed at all, it would fall to option 3) and download the pre-built webui from huggingface.

[Orion-zhen]

Oh! So that's the case. We cannot assume that all users don't have npm-related packages installed on their computers; therefore, for maximum compatibility, we must explicitly build the webui via npm within this PKGBUILD.

[Orion-zhen]

Thank you for your professional and meticulous help!

[zoitrok]

Just gave b9222-3 a spin, and the webui works!

There would be other solutions as there are three paths -- but I think pre-building and placing in build/ would add additional complexity. Fetching from huggingface adds another point of failure.
The current solution adds dependencies, but I think it's cleaner to have it self-contained.