Superminaren/llama.cpp
1
0
Fork 0
mirror of https://github.com/ggml-org/llama.cpp.git synced 2026-09-11 04:56:56 +02:00
Code Issues Packages Projects Releases Wiki Activity

cmake : update test-cmake README notes [no ci]

Browse Source
This commit is contained in:
Daniel Bevenius
2026-08-10 13:02:12 +02:00
parent 22443d0e89
commit ca9ca71f08
1 changed files with 44 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
examples/test-cmake/README.md
+44 -1
View File
@@ -35,7 +35,11 @@ Build/run this project using the installation created above:
load_backend: loaded CPU backend from /home/danbev/work/ai/llama.cpp/examples/test-cmake/install/lib/llama.cpp/libggml-cpu-alderlake.so
[test-cmake] Backend initialized.
```
Notice that the llama.cpp version is currently `0.1.0-dev-b10335`.
Notice that the llama.cpp version is currently `0.1.0-dev-b10335`. And also note
that the cpu backend module is not using a semver. I was not sure about this a
it these are used as plugins and we look for `.so` files in this case. But this
migth be an issue if we have multiple versions in the same directory as a new
version would overwrite the old file.
### Nightly builds
Currently nightly/daily builds use build number if the format `b10333`. This will
@@ -52,4 +56,43 @@ is for the next version, for example `0.2.0`. TODO: need to figure this out and
if this can be automated so that there are no builds that get created in the
time between the actual release and a new nightly/daily build.
```console
$ wget https://github.com/danbev/llama.cpp/releases/download/b10339/llama-b10339-bin-ubuntu-x64.tar.gz
$ mkdir tmp; cd tmp
$ mv ../llama-b10339-bin-ubuntu-x64.tar.gz .
$ tar xvf llama-b10339-bin-ubuntu-x64.tar.gz
(venv) $ ls llama-b10339/libllama.*
llama-b10339/libllama.so llama-b10339/libllama.so.0 llama-b10339/libllama.so.0.1.0
venv) $ ./llama-b10339/llama-cli --version
version: 0.1.0-dev-b10339 (build 10339, commit c8fe5edf5)
built with GNU 11.4.0 for Linux x86_64
(venv) $ ./llama-b10339/llama-server --version
version: 0.1.0-dev-b10339 (build 10339, commit c8fe5edf5)
built with GNU 11.4.0 for Linux x86_64
```
As mentioned about the ggml-cpu backeds are not using semantic versioning:
```console
(venv) $ ls llama-b10339/libggml-cpu-*
llama-b10339/libggml-cpu-alderlake.so llama-b10339/libggml-cpu-piledriver.so
llama-b10339/libggml-cpu-cannonlake.so llama-b10339/libggml-cpu-sandybridge.so
llama-b10339/libggml-cpu-cascadelake.so llama-b10339/libggml-cpu-sapphirerapids.so
llama-b10339/libggml-cpu-cooperlake.so llama-b10339/libggml-cpu-skylakex.so
llama-b10339/libggml-cpu-haswell.so llama-b10339/libggml-cpu-sse42.so
llama-b10339/libggml-cpu-icelake.so llama-b10339/libggml-cpu-x64.so
llama-b10339/libggml-cpu-ivybridge.so llama-b10339/libggml-cpu-zen4.so
```
If we were to install a new version, these backends would be overwritten which
will not work. We need a solution for this and I think it would be most consistent
to use the semver for them as well. An alternative would be to place them in
a versioned directory but I'm not sure how well that would work for projects
integrating ggml into their projects. The might be building with a specific
ggml backends directory (GGML_BACKEND_DIR) and I don't think we can force this
upon them. I'll look into this but in the ggml repo as that is where the semver
changes for ggml are taking place.
_wip_