Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set GGML_BUILD_NUMBER to the correct version when building from pypi tarball #1979

Open
4 tasks done
booxter opened this issue Mar 22, 2025 · 0 comments · May be fixed by #1980
Open
4 tasks done

Set GGML_BUILD_NUMBER to the correct version when building from pypi tarball #1979

booxter opened this issue Mar 22, 2025 · 0 comments · May be fixed by #1980

Comments

@booxter
Copy link

booxter commented Mar 22, 2025

Prerequisites

Please answer the following questions for yourself before submitting an issue.

  • I am running the latest code. Development is very rapid so there are no tagged versions as of now.
  • I carefully followed the README.md.
  • I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
  • I reviewed the Discussions, and have a new bug or useful enhancement to share.

Expected Behavior

When I build the package from the source tarball uploaded to PyPI, I expect PACKAGE_VERSION in ggml-version.cmake file set to the same version as extracted from git when building directly from the git repo.

Current Behavior

$ grep PACKAGE_VERSION result/lib/python3.12/site-packages/lib/cmake/ggml/ggml-version.cmake | grep '^set'
set(PACKAGE_VERSION "0.0.1"

This is probably because while the published tarball includes .git, the checkout done by actions/checkout in the publish workflow doesn't fetch full depth of the git repo, so the checkout turns out shallow.

This is what is seen during the build:

python3.12-llama-cpp-python> CMake Warning at vendor/llama.cpp/ggml/CMakeLists.txt:298 (message):
python3.12-llama-cpp-python>   GGML build version fixed at 1 likely due to a shallow clone.

I think this can be fixed by setting fetch-depth to 0 for the publish workflow. Of course, this may be not very optimal because then the resulting tarball will have to include complete git repo. (The difference in my local tests is around 100Mb.)

Perhaps an alternative fix is to calculate the version during the sdist build, then storing it inside the tarball as a file; finally, read the version from this file during the build, if it's present.

booxter added a commit to booxter/llama.cpp that referenced this issue Mar 22, 2025
This will enable llama-cpp-python to generate the file during sdist
build and include it into the final tarball. The file then will be
picked up by the package build to include the correct version, even
without full git checkout included.

Related: abetlen/llama-cpp-python#1979

Signed-off-by: Ihar Hrachyshka <[email protected]>
booxter added a commit to booxter/llama-cpp-python that referenced this issue Mar 22, 2025
With that, builds using tarball will still have the correct cmake
package version for ggml.

This assumes the file is read by llama.cpp build system, see:
ggml-org/llama.cpp#12509

Fixes abetlen#1979

Signed-off-by: Ihar Hrachyshka <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant