Working towards making the build.zig build actually useful for
users..
For building a full runtime distribution in /usr or /opt/nvim or
whatever, use
sudo zig build install -p /usr
by default "zig build" will now work like "make" e.g. just build the binary
and the generated parts of the runtime. This will work for development,
but you need to use both parts of the runtime, just like with
an "uninstalled" cmake build:
zig build
VIM=. ./zig-out/bin/nvim --clean --cmd "set rtp+=./zig-out/runtime"
As a wrapper, `zig build run_dev` can be used
Problem:
`clint.py` is the last python in our codebase, and beyond that it needs
some cleanup. And it lacks tests, so modifying it can be painful.
Also, we need a way to add ad-hoc lint rules for *Lua*, so it will help
to have our ad-hoc rules for C in the same language (the scripts may
share functions/techniques): https://github.com/neovim/neovim/issues/28372
Solution:
- convert to `clint.lua` (mostly AI-generated, but it now has test
coverage, unlike `clint.py`)
- drop rules that are no longer needed:
- "readability/multiline_string"
- technially still relevant, but very uncommon so doesn't really matter.
- "--line-length"
- Not used in the old clint.py, nor the new clint.lua.
- "comment whitespace" check
- It is enforced by uncrustify.
- "TODO" check
- The `-google-readability-function-size` clang-tidy rule enforces
"TODO(user)" format. (It was already enabled long ago.)
Problem:
No way to detect at runtime if the build includes unibilium (or whatever
terminfo layer we swap it with later).
Solution:
Support `has('terminfo')`.
Problem:
On macOS Tahoe, `make unittest` started failing with the following error.
````
test/unit/testutil.lua:784: test/unit/testutil.lua:768: (string) '
test/unit/testutil.lua:295: declaration specifier expected near 'ipc_info_object_type_t' at line 2297'
exit code: 256
stack traceback:
test/unit/testutil.lua:784: in function 'itp_parent'
test/unit/testutil.lua:822: in function <test/unit/testutil.lua:812>
````
Solution:
Update filter_complex_blocks.
> The macOS 13 runner image will be retired by December 4th, 2025.
Update to the macos-15-intel runner.
It seems that runners ending with "large" require an enterprise plan, so
macos-15-intel is the only other available macOS Intel runner.
- Bump zig version to 0.15.1 and workaround zig fetch hang (ziglang/zig#24916)
- add mac os zig build (currently without luajit, linker failure)
- Add windows zig build, currently with very limited testing
This is matters for cross-compiling where we might not
be able to run the "nvim" binary on the host.
Instead reimplement the helptags extractor as a small
lua script, which we can run on the host using the nlua0
helper already used for other generator scripts.
Tested using cross-compiling from linux:
zig build -Dcross=true -Dtarget=x86_64-windows nvim_bin
Note: not fully functional without a runtime, which still has to be
fuddled with manually
Macos and windows builds require a recent zig 0.15+dev version
As this zig master branch is currently too much in flux, we can't make
our CI depend on zig master.
Revisit CI after zig 0.15 release or at least feature freeze.
Problem:
We temporarily disabled linux arm ci because of stability issues with
the runner. #32339 Since then, the hardware was changed, so we can try
re-enabling ARM linux CI. https://github.com/actions/partner-runner-images/issues/47#issuecomment-2678170225
Solution:
- re-enable arm linux ci. reverts 8e4b77134a
- also use arm image for these jobs, where arm seems to run much faster:
- `lint` (step: `clang-tidy`)
- master: 1m5s
- this pr (linux ARM): 37s
- `clang-analyzer` (step: `cmake --build ...`)
- master: 10m
- this pr (linux ARM) 5m 55s
- `with-external-deps` (step: `Build`)
- master: 26s
- this pr (linux ARM): 21s
NEW BUILD SYSTEM!
This is a MVP implementation which supports building the "nvim" binary,
including cross-compilation for some targets.
As an example, you can build a aarch64-macos binary from
an x86-64-linux-gnu host, or vice versa
Add CI target for build.zig currently for functionaltests on linux
x86_64 only
Follow up items:
- praxis for version and dependency bumping
- windows 💀
- full integration of libintl and gettext (or a desicion not to)
- update help and API metadata files
- installation into a $PREFIX
- more tests and linters
Enable translations in the GCC release job, as it's the fastest.
Although there aren't many tests for translation behavior, this still
allows ensuring that Nvim isn't broken when translations are enabled.
This automatically downloads and uses the correct luals binary for the
currently used system. `make luals` will run luals on all lua files in
`runtime`.
We download lua-language-server manually instead of relying on
contributors downloading it on their own (like with stylua) as
lua-language-server is updated frequently which may cause unnecessary
friction. Therefore, we download a pinned version of luals which we then
can manually bump when needed. This can be re-evaluated if luals becomes
more stable in the future.
Currently this is not run when using `make lint` since cmake style "file
caching" doesn't seem possible at the moment. This is because checking a
single file doesn't seem to work.
Work on https://github.com/neovim/neovim/issues/24563.
Problem: Some CI jobs are redundant: `RelWithDebInfo` is already tested
on Linux-Arm64; `MinSizeRel` and Ninja Multi Config are not sufficiently
relevant in practice to spend CI cycles on.
Solution: Remove `build-types` job.
Tests should not rely on being run inside a git clone, so the Linux
builds cover this use case. The macOS builds will continue running with
the .git directory so there's still unix-ish coverage within a git
clone.
This ensures that no tests fail due to differences between release and debug builds.
The release build-type check is now unnecessary, too, so remove it.
Problem: Adding support for modern Nvim features (reflow, OSC 8, full
utf8/emoji support) requires coupling libvterm to Nvim internals
(e.g., utf8proc).
Solution: Vendor libvterm at v0.3.3.
Auto-merging is a useful feature by github, but it requires required
checks which requires a few adjustments. The primary change is that
required checks can't use `paths` or `paths-ignore` as that risks not
running the job, and required checks must always be run.
A workaround for this is to introduce a dummy workflow which is used for
every path not used in the real workflow. That way the required job is
"always" run as far as github is concerned. The workaround is unweildly
so it's only useful to do it for costly workflows where the potential
benefits are big. If not it's better to simply remove any `paths` or
`paths-ignore` from a workflow instead.
Add more filters so that LuaJIT can parse headers on macOS 14.
The system headers use a style of enum introduced in C++11 (and allowed
as an extension in C by clang) of the form:
enum Name : Type {
The system headers also use bitfields in the mach_vm_range_recipe* types:
struct Foo { int bar : 32; }
Neither of these constructs can be parsed by LuaJIT, so filter the lines
out. Neither of these declarations are used by neovim's unittests.
There is a (now closed) issue about bitfields for LuaJIT:
https://github.com/LuaJIT/LuaJIT/issues/951Fixes#26145.
Python 3.12+ throws an error if you try to install a package in an
externally managed environment. Using `--break-system-packages` is not
recommended for personal use, but for CI it should be fine and is
probably the most straightforward solution.
`github.ref` is now defined for both pull requests and pushes, meaning
that it can be used to simplify the concurrency group.
`cancel-in-progress` is set to true only if the trigger is a pull
request, as we don't want master runs to cancel each other out.
Problem: No test coverage on ARM.
Solution: Add `macos-14` tests, which now run on M1. Skip unit tests as these don't work on M1, see #26145. Also test universal build on M1.
Note: `macos-14` will be `macos-latest` in Q2 2024, so we'll want to switch these to keep Intel and unittest coverage on macos (while GH still offers Intel runners).
Explicitly set the build type for both deps and Nvim. They are already
explicitly set on Windows to RelWithDebInfo. Now also explicitly set
them to Debug on POSIX.
