I rarely care about the status of the x86 builds, so this commit only
runs them if the x64 builds succeed. If the x64 build is successful but
the x86 build is not, the cache for the x64 build should kick in and the
x86 build should follow shortly after, if it's necessary to iterate on
it.
Updated the GitHub Actions workflow so x86 only runs after x64 succeeds.
Changed:
- Split the old matrix job into two explicit jobs: build-x64 and build-x86.
- Added needs: build-x64 on the x86 job, which enforces the dependency.
Aliases remain small because size is important and they are already
maximum speed. The distribution is ~10MB (~22%) larger, but C++ builds
with this toolchain are ~25% faster.
By breaking independent parts of the build into stages breaks implied
dependencies between those parts. A tool built later will not require
rebuilding when earlier unrelated tools are changed. That includes
upgrades to require new downloads. Most tools can be upgraded without
requiring unnecessary rebuilds.
When a build command is sufficiently simple, GNU Make simulates a shell
("fast") instead of starting a real shell ("slow"). This simulation is
defective, such as incorrectly resolving executables, ignoring $PATHEXT,
and so on. The "fast" path does not appear to be faster, so rather than
fix it just disable it with a small patch.
The convention is ALL_CAPS is intended for user override and all_lower
is for internal variables. Introduce CC and CXX to enable finer control
over the compiler (ccache, etc.).
The official Vim project no longer hosts older versions of Vim, and the
original Vim host is now gone. Due to the hashes, we can safely download
from anywhere stable, so let's try this mirror.
Now that GGML's version has been bumped from 0.9.4 to 0.9.5, the
hardcoded version in llama.mak is no longer correct. Instead, parse the
version number out of the CMakeLists.txt and retrieve the commit hash
using git if available.
This should cut back on most, though not all, build script updates. The
mtmd subdirectory still requires a manual listing because it only uses a
few files. The generated build info source was moved out of the way so
that it doesn't match globs. It also now builds the llama.dll.a import
library.
See #309. Closes#316.
Go (gc toolchain) does not yet support bigobj, and so cgo is currently
incompatible with w64dk. Bootstrapping Go 1.4 from C still works, but
even that's increasingly impractical anyway.
Also switch to GitHub releases because it apparently not subject to
naive Expat security policies, making it more reliable. Expat only
parses trusted inputs in w64dk, and so is unaffected by security issues.
Updates are generally unnecessary. Unfortunately Expat's repository has
an unconventiontional tagging convention, and tags do not exactly match
the version, so the ARG will no longer work on its own, which is why I
had avoided its GitHub releases for so long.
