Looks like the github actions image now has ninja installed.
This causes a failure; we effectively do
$ (
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
)
$ make VERBOSE=1
[...]
cd build; cmake .. -G "Ninja" \
-DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_EXPORT_COMPILE_COMMANDS=1
Re-run cmake no build system arguments
CMake Error: Error: generator : Ninja
Does not match the generator used previously: Unix Makefiles
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
"make" fails because it runs from top-level, with GNUMakefile's logic to
use -GNinja if available. This is at odds with the direct cmake invocation,
which defaults to -G'Unix Makefiles'.
We shouldn't mix direct cmake invocation and the top-level Makefiles, so
run make from the build directory instead.
While at it, update some test invocations missed in 8d6fdfd9de
(Remove cmake "test" target, 2025-02-02). This should
help avoid missing test failure output in CI, see
https://github.com/fish-shell/fish-shell/issues/11116#issuecomment-2629406479
These are supposed to be small, so we dump the redundant fish_indent
and fish_key_reader - the fish binary can do those jobs too (both as
builtins and if called via symlinks of that name).
We still keep tarballs instead of just compressing so that we have a
file called "fish" and not "fish-amd64-linux"
Revert "README for this fork"
This reverts commit 97db461e7f.
Revert "Allow foo=bar global variable assignments"
This reverts commit 45a2017580.
Revert "Interpret () in command position as subshell"
This reverts commit 0199583435.
Revert "Allow special variables $?,$$,$@,$#"
This reverts commit 4a71ee1288.
Revert "Allow $() in command position"
This reverts commit 4b99fe2288.
Revert "Turn off full LTO"
This reverts commit b1213f1385.
Revert "Back out "bind: Remove "c-" and "a-" shortcut notation""
This reverts commit f43abc42f9.
Revert "Un-hide documentation of non-fish shell builtins"
This reverts commit 485201ba2e.
This is an experiment to see if it causes any of the tests to flake and/or if it
even appreciably speeds up CI to begin with.
I note that there are tests added in 8bf8b10 that mutate global terminal state
but also note that local tests without CTEST_PARALLEL_LEVEL set at all have been
running to completion just fine without any observed flakiness *and* that our
Cirrus CI tests have this hard-coded to 6.
The apple-codesign crate has a fairly aggressive MSRV policy, and the
compiler itself still targets 10.12 which is well below the minimum
version of macOS for aarch64. Just use stable.
We get "undefined reference to `__memmove_chk'" when compiling
pcre2 (via pcre2-sys) on newer Ubuntu.
That one is used with higher fortify_source levels, and Ubuntu 24.04
defaults to 3, while my arch system (where I cannot reproduce)
defaults to 2.
For x86_64 and cross-compiled for aarch64, manually triggered
It *seems* to work, but I had to explicitly disable gettext for it (which is AFAICT currently non-functional under musl anyway).
Also it will create one .zip containing two .tar.xzs. It is about 8MB, which should be fine, tbh.
When we changed our default from RelWithDebInfo to Debug, we inadvertently ended
up with all CI building and running in Debug mode. Change at least one of them
back to Release to make sure we don't have any optimizations that cause funky
stuff.
I'm changing the Ubuntu CI image because it's hopefully the fastest (since rust
is relatively dog-slow to compile in release mode).
This automatically assigns the 'completions' label and the 'fish next-3.x'
milestone to completions-only PRs.
A completions-only PR is defined as being one that touches
share/completions/*.fish but does not touch any files outside of share/
CARGO_NET_GIT_FETCH_WITH_CLI uses the `git` executable instead of the rust
git2 crate/lib, which speeds things up and is known to resolve some issues
fetching the registry or individual crates.
This is to work around a specific issue with git-resident Cargo.toml
dependencies (e.g. terminfo) that keep randomly failing to download under macOS
CI.
It appears we can't find a system that ships rustc >= 1.67 and < 1.70,
so keeping it at 1.67 gains nothing.
1.70 is used in Debian 13, so that will be able to build fish out of
the box (12 was on 1.63 which was already too low).
These are dog-slow at building, and the tests themselves are barely
sped up running as release.
Given that we have ~10 minute build and ~3 minute test time on Github
Actions on macOS, let's see if this speeds it up
(we can also do it for the others, but the most important is the
slowest test because that's what stops the checkmark appearing)
This was pretty annoying on rust release day, because it introduced
new warnings.
Specifically 1.73 introduced a spurious one about PartialOrd and Ord
disagreeing when both were in fact #derive-d.
- https://github.com/ATiltedTree/setup-rust has not been committed to since May
2022, I am uncertain about how widely used it is.
- It appears to have a bug with restoring its internal cache whenever there
comes a new stable version (immediate guess would be the cache-key does not
resolve `stable` to a specific version, which somehow breaks rustup, but I have not investigated)
- https://github.com/dtolnay/rust-toolchain is a more sensible take of https://github.com/actions-rs/toolchain,
where the original repo appears to be unmaintained.
It is implemented in one file of yaml/bash
https://github.com/dtolnay/rust-toolchain/blob/master/action.yml, we could
easily fork it if it becomes unmainted, unlike the other actions which uses
unnecessary javascript
