GitLab

This commit introduces a more friendly way to build Ollama dependencies
and the binary without abusing `go generate` and removing the
unnecessary extra steps it brings with it.

This script also provides nicer feedback to the user about what is
happening during the build process.

At the end, it prints a helpful message to the user about what to do
next (e.g. run the new local Ollama).

The subprocess change moved the build directory
arm64 builds weren't setting cross-compilation flags when building on x86

This should resolve a number of memory leak and stability defects by allowing
us to isolate llama.cpp in a separate process and shutdown when idle, and
gracefully restart if it has problems.  This also serves as a first step to be
able to run multiple copies to support multiple models concurrently.

For old macs, accelerate seems to cause crashes, but for
AVX2 capable macs, it does not.

This also refines the build process for the ext_server build.

Make sure we're building an x86 ext_server lib when cross-compiling

This switches darwin to dynamic loading, and refactors the code now that no
static linking of the library is used on any platform

* update cmake flags for intel macOS

* remove `LLAMA_K_QUANTS`

* put back `CMAKE_OSX_DEPLOYMENT_TARGET` and disable `LLAMA_F16C`

Refactor where we store build outputs, and support a fully dynamic loading
model on windows so the base executable has no special dependencies thus
doesn't require a special PATH.

This changes the model for llama.cpp inclusion so we're not applying a patch,
but instead have the C++ code directly in the ollama tree, which should make it
easier to refine and update over time.

Run the server.cpp directly inside the Go runtime via cgo
while retaining the LLM Go abstractions.