build_info in common/CMakeLists.txt and Git

[atroyn]

What is the purpose of the build_info command in the CMakeLists for the common lib? I would like to be able to build llama.cpp without it being a part of a GitHub repo, but it seems without .git, build_info fails, causing the overall build to fail.

I haven't succeeded in turning this off.

[tbogdala]

The path of least resistance is to use another CMake setup and just add_subdirectory("llama.cpp") so that you can take advantage of all the engineering they do in their build setup. And even more importantly than that: you wont have to recode it every time they refactor and break your own build scripts. :)

Part of doing that route means the build_info automatically will get built with cmake, and thus becomes a non-problem.

[bandoti]

Actually, the recommended way is to use the CMake package.

Take a look at the examples/main-cmake-pkg. In order to use this, you will have to build llama.cpp with CMake.

The CMakeLists.txt file shows simple usage pattern. But this is preferred because it follows the common CMake find module pattern.

[tbogdala]

I see what you mean now. Part of the build info is the git commit. As for why it's there, you can search for LLAMA_BUILD_NUMBER to get an idea of where it's used.

But, on to a solution: you could just create it by hand. Look at llama.cpp/common/build-info.cpp.in and copy it to 'build-info.cpp' and just edit the file so it has numbers and strings as appropriate. I suppose, ideally those numbers would represent the state of the repo you're compiling, but it probably could be anything.

[atroyn]

@bandoti Thanks, but this example doesn't address what I'm trying to accomplish - it requires that I first build or install llama.cpp, which is not what I'm doing.

@tbogdala will give that a try, it was my fallback here, just wondering if @ggerganov had a better idea.

[slaren]

The common library and build-info should probably be skipped when not building the examples and tests. If you are using the examples code you are kind of on your own, but otherwise build-info should not be necessary.

[bandoti]

No problem—well, to be able to build it without the GitHub repo you're going to have to do custom modifications to the CMakeLists.txt and also probably hand-build the source file generated by:

https://github.com/ggerganov/llama.cpp/blob/master/common/build-info.cpp.in

[slaren]

Can you check if these changes to the CMakeLists.txt fix your problem? You need to build with -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF, which should be the default when building llama.cpp as a subproject.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index a3132063..3af0250b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -70,8 +70,10 @@ option(LLAMA_BUILD_SERVER   "llama: build server example" ${LLAMA_STANDALONE})
 # 3rd party libs
 option(LLAMA_CURL "llama: use libcurl to download model from an URL" OFF)

-# Required for relocatable CMake package
-include(${CMAKE_CURRENT_SOURCE_DIR}/cmake/build-info.cmake)
+if (LLAMA_BUILD_EXAMPLES)
+    # Required for relocatable CMake package
+    include(${CMAKE_CURRENT_SOURCE_DIR}/cmake/build-info.cmake)
+endif()

 # override ggml options
 set(GGML_SANITIZE_THREAD    ${LLAMA_SANITIZE_THREAD})
@@ -188,7 +190,9 @@ install(FILES "${CMAKE_CURRENT_BINARY_DIR}/llama.pc"
 # programs, examples and tests
 #

-add_subdirectory(common)
+if (LLAMA_BUILD_EXAMPLES OR LLAMA_BUILD_TESTS)
+    add_subdirectory(common)
+endif()

 if (LLAMA_BUILD_TESTS AND NOT CMAKE_JS_VERSION)
     include(CTest)

[atroyn]

I'm using functions in common so this won't work for me.

[slaren]

The common library is intended to be used exclusively by the llama.cpp examples, and that's what it is tailored for. That said, if you submit a patch to the build script so that build-info writes some generic strings (to build-info.cpp) when building without a git repository, that would likely be accepted.

[atroyn]

that makes sense, will work around for now - I found the utility methods in common to be quite useful for my own application without having to re-invent the wheel

[atroyn]

maybe the real workaround is to just eliminate dependencies on common by porting relevant code to my own