Remove the following C++ functions/methods, which have no callers:
fallback.cpp:
- wcstod_l
proc.cpp:
- job_t::get_processes
wutil.cpp:
- fish_wcstoll
- fish_wcstoull
Also drop unused configure checks/defines:
- HAVE_WCSTOD_L
- HAVE_USELOCALE
This is more complicated than it needs to be thanks to the presence of CMake and
the C++ ffi in the picture. rsconf can correctly detect the required libraries
and instruct rustc to link against them, but since we generate a static rust
library and have CMake link it against the C++ binaries, we are still at the
mercy of CMake picking up the symbols we want.
Unfortunately, we could detect the gettext symbols but discover at runtime that
they weren't linked in because CMake was compiled with `-DWITH_GETTEXT=0` or
similar (as the macOS CI runner does). This means we also need to pass state
between CMake and our build script to communicate which CMake options were
enabled.
The new asan exit handlers are called to get proper ASAN leak reports (as
calling _exit(0) skips the LSAN reporting stage and exits with success every
time).
They are no-ops when not compiled for ASAN.
Use a "cmake-vendored" directory if it exists, to avoid accessing the
network if it's available, and a target to create an appropriate tarball
to create that directory.
Rust has multiple sanitizers available (with llvm integration).
-Zsanitizer=address catches the most likely culprits but we may want to set up a
separate job w/ -Zsanitizer=memory to catch uninitialized reads.
It might be necessary to execute `cargo build` as `cargo build -Zbuild-std` to
get full coverage.
When we're linking against the hybrid C++ codebase, the sanitizer library is
injected into the binary by also include `-fsanitize=address` in CXXFLAGS - we
do *not* want to manually opt-into `-lasan`. We also need to manually specify
the desired target triple as a CMake variable and then explicitly pass it to all
`cargo` invocations if building with ASAN.
Corrosion has been patched to make sure it follows these rules.
The `cargo-test` target is failing to link under ASAN. For some reason it has
autocxx/ffi dependencies even though only rust-native, ffi-free code should be
tested (and one would think the situation wouldn't change depending on the
presence of the sanitizer flag). It's been disabled under ASAN for now.
The FISH_RUST_TARGET_DIR is not set for Tests.cmake, the target_dir will set to
$CARGO_MANIFEST_DIR/target. But if build.target-dir or CARGO_TARGET_DIR is set,
the real target_dir doesn't at the $CARGO_MANIFEST_DIR/target. It causes failure
in cargo test. Then, set --target-dir for cargo test.
Closes#9600
a lynx-internal hash of div.contents collided with em>a which caused
built-in styling to render much of entire pages as emphasized links.
Since switching from doxygen, we haven't had a <div class="contents">
so this workaround is no longer needed.
The previous check was including these as relative includes, meaning the actual
system header files weren't actually being explicitly included and the check
could spuriously fail.
CMAKE_EXTRA_INCLUDE_FILES doesn't seem to have a way to specify that the
includes should be treated as system/global includes and CHECK_TYPE_SIZE() isn't
documented as being affected by any other variables that do, so switch to
another method altogether.
This requires that `struct winsize` have a member `ws_row`, but as best as I can
tell that is always the case.
Closes#9279.
g++ 4.8 emits a bogus warning on code like foo{}. Add a compiler flag
-Wno-missing-field-initializers if that warning is detected, because it
is annoying.
GIT_WORK_TREE is an environment variable which tells git where the
worktree is. It may be set by the user or by git itself, e.g. when
running `git rebase -i --exec ...`. If it is set, it overrides the
working directory, causing the `git checkout` from FetchContent_Populate
to fail. Clear this variable.
Do the same for GIT_DIR for the same reason.
A way to reproduce the failure that this commit fixes is:
git rebase -i HEAD^^^ --exec 'ninja -C /path/to/build/dir fish'
prior to this commit, using the fetched PCRE2, this would fail in CMake.
GIT_SHALLOW 1 here improves generation speed and _deps in the build
dir like is 6 or 7 MB less according to `du`.
Bump the minimum PCRE2 to 10.35 on account of we use
PCRE2_SUBSTITUTE_LITERAL.
This switches to using the CMake FetchContent path to dynamically download
and build PCRE2, allowing us to drop the vendored sources.
The FISH_USE_SYSTEM_PCRE2 CMake option is kept, but if false it now means
fetch-and-build PCRE2 rather than building vendored sources.
Note FetchContent was introduced in CMake 3.11. That is now a prerequisite
for building fish with FISH_USE_SYSTEM_PCRE2 disabled.
Static destructors cause the destructor for a global object to run when
the program exits. They are bad because:
1. Registering them takes time and memory at startup
2. Running them takes time at shutdown and also they may have weird
interactions.
This shaves about 12k off of the binary size.
Unfortunately gcc does not support this flag.
This is a less-intrusive version of 95845b1, and only disables the
search for frameworks for libintil (sometimes shipped with Mono, but not
usable for compilation).
Closes#5244.
glibc 2.30 and up emit an ugly depreciation warning on
`#include <sys/sysctl.h>` - this patch makes the build system fail the
include test for `sys/sysctl.h` by forcibly setting `-Werror` before the
call to `check_include_files` (which internally uses `try_compile`) to
get `HAVE_SYS_SYSCTL` to not be defined (even if it's there) if it would
cause such a depreciation message to be emitted.
Ideally, we would not have to manually massage `CMAKE_C_FLAGS` before
calling `check_include_files` and could just tweak that to either always
or conditionally try compilation with `-Werror`, but try_compile doesn't
actually use any overridden `CMAKE_C_FLAGS` values [0] (dating back to
2006).
[0]: https://cmake.org/pipermail/cmake/2006-October/011649.html
We apparently vendored it for the sake of attempting to support
old cmake versions:
7aefaff298.
"This file can be dropped once the minimum version of CMake for fish is 3.11.0"
So, drop it like it's hot.
Recent synopsis changes move from literal code blocks to
[RST line blocks]. This does not translate well to HTML: it's not
rendered in monospace, so aligment is lost. Additionally, we don't
get syntax highlighting in HTML, which adds differences to our code
samples which are highlighted.
We hard-wrap synopsis lines (like code blocks). To align continuation
lines in manpages we need [backslashes in weird places]. Combined with
the **, *, and `` markup, it's a bit hard to get the alignment right.
Fix these by moving synopsis sources back to code blocks and compute
HTML syntax highlighting and manpage markup with a custom Sphinx
extension.
The new Pygments lexer can tokenize a synopsis and assign the various
highlighting roles, which closely matches fish's syntax highlighing:
- command/keyword (dark blue)
- parameter (light blue)
- operator like and/or/not/&&/|| (cyan)
- grammar metacharacter (black)
For manpage output, we don't project the fish syntax highlighting
but follow the markup convention in GNU's man(1):
bold text type exactly as shown.
italic text replace with appropriate argument.
To make it easy to separate these two automatically, formalize that
(italic) placeholders must be uppercase; while all lowercase text is
interpreted literally (so rendered bold).
This makes manpages more consistent, see string-join(1) and and(1).
Implementation notes:
Since we want manpage formatting but Sphinx's Pygments highlighing
plugin does not support manpage output, add our custom "synopsis"
directive. This directive parses differently when manpage output is
specified. This means that the HTML and manpage build processes must
not share a cache, because the parsed doctrees are cached. Work around
this by using separate cache locations for build targets "sphinx-docs"
(which creates HTML) and "sphinx-manpages". A better solution would
be to only override Sphinx's ManualPageBuilder but that would take a
bit more code (ideally we could override ManualPageWriter but Sphinx
4.3.2 doesn't really support that).
---
Alternative solution: stick with line blocks but use roles like
:command: or :option: (or custom ones). While this would make it
possible to produce HTML that is consistent with code blocks (by adding
a bit of CSS), the source would look uglier and is harder to maintain.
(Let's say we want to add custom formatting to the [|] metacharacters
in HTML. This is much easier with the proposed patch.)
---
[RST line blocks]: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#line-blocks
[backslashes in weird places]: https://github.com/fish-shell/fish-shell/pull/8626#discussion_r782837750
+ No functional change here, just renames and #include changes.
+ CMake can't have slashes in the target names. I'm suspciious of
that weird machinery for test, but I made it work.
+ A couple of builtins did not include their own headers, that
is no longer the case.
Our tests typically run in their own environment, which is great for
normal tests.
However for the coming translation test, we don't want to copy the .po
files into the test environment, so it's nice to have a way out.
In most cases, like math, we want C-semantics for floating point
numbers. In particular "." needs to be the decimal separator.
Instead, we pay the price in printf, which is currently the sole place
to output in locale-specific numbers and attempt to read them and
C-style ones.
- Only check for HAVE_CLOCK_GETTIME and HAVE_FUTIMENS on Linux, since
they are only used to implement a Linux-specific workaround related
to mtime precision.
- Make sure that hack is limited to Linux builds
- HAVE_SYS_SYSCTL_H was unused, but we should have been using it
- HAVE_TERMIOS_H was unused, remove it
The only functional change is that unix machines with clock_gettime
and futimens will not bother with a Linux-specific hack, and won't
waste time checking for either during cmake configuration either.
sphinx-build supports the -j option to use multiple processes. Start using
it. This reduces the time to build the docs on my Linux box from 11 seconds
to about 4.
Note this doesn't work on macOS since -j is ignored there (see sphinx-build
PR 6879).
This lets us run non-fish targets (such as `fish_tests`) under a clean
test environment without running into the fish-specific payload
configuration now carried out by `test_driver.sh` which expects a
`.fish` payload that it will run under a deterministically configured
instance of fish, running in an environment initialized by
`test_env.sh`.
This should fix the problem with in-tree builds leaving detritus behind
after a `make test` when `fish_tests` would be executed without
`test_driver.sh` - it is now executed under `test_env.sh` instead.
For littlecheck/pexpect this just unconditionally enables color.
I have no idea what happens if you run cmake outside of a terminal
, but the worst that can happen is that *errors* have color
escapes in them.
If someone figures out how to get cmake to tell us if it's running in
a terminal, we can add a check.
This means instead of printing at least two lines per successful test,
we overwrite one line again and again with the current status, and
for *failed* (i.e interesting) tests we print the output.
Makes test failures much more visible.
`test:foo` is not allowed by CMake ("reserved name") and `test/foo`
won't work since CMake doesn't allow targets to have a directory
separator in their name.
Even though we are using CMake's ctest for testing, we still define our
own `make test` target rather than use its default for many reasons:
* CMake doesn't run tests in-proc or even add each tests as an
individual node in the ninja dependency tree, instead it just bundles
all tests into a target called `test` that always just shells out to
`ctest`, so there are no build-related benefits to not doing that
ourselves.
* CMake devs insist that it is appropriate for `make test` to never
depend on `make all`, i.e. running `make test` does not require any
of the binaries to be built before testing.
* The only way to have a test depend on a binary is to add a fake test
with a name like "build_fish" that executes CMake recursively to
build the `fish` target.
* It is not possible to set top-level CTest options/settings such as
CTEST_PARALLEL_LEVEL from within the CMake configuration file.
* Circling back to the point about individual tests not being actual
Makefile targets, CMake does not offer any way to execute a named
test via the `make`/`ninja`/whatever interface; the only way to
manually invoke test `foo` is to to manually run `ctest` and specify
a regex matching `foo` as an argument, e.g. `ctest -R ^foo$`... which
is really crazy.
With this patch, it is now possible to execute any single test by name,
by invoking the build directly, e.g. to run the `universal.fish` check:
`cmake --build build --target universal.fish` or
`ninja -C build universal.fish`. Unfortunately, this is not integrated
into the Makefile wrapper, so `make universal.fish` won't work (although
this can potentially be hacked around).
Instead of compiling `fish_tests.cpp` dynamically with weakly-linked
symbols and asking it to print the list of all available tests, we
use a magic string `#define`'d as a no-op to allow CMake to regex search
for matching test groups. This speeds up configuration somewhat (by not
compiling anything), but more importantly, it's much less brittle and
doesn't involve and linker dark magic.
There's of course still no getting around the fact that it's really ugly.
* Remove safe_strerror, safe_perror and safe_append
This no longer works on new glibcs because they removed sys_errlist.
So just hardcode the relevant errno messages (and phrase them better).
Fixes#4183.
Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Cmake accepts both absolute and relative paths in CMAKE_INSTALL_DATADIR.
For the latter case CMAKE_INSTALL_PREFIX is being prepended
automatically. %{rel_datadir} is derived from CMAKE_INSTALL_DATADIR
which was assumed to be relative and otherwise causes issues in a .pc
file where prefix is being prepended unconditionally.
Make sure %{rel_datadir} is relative by calculating RELATIVE_PATH from
CMAKE_INSTALL_PREFIX to CMAKE_INSTALL_FULL_DATADIR which is known to be
absolute.
Fixes#8150
This has cheesy pattern matching that I'm not entirely sure adds
anything?
Surely if we add something to share/web_config that should be
installed *by default*?
Anyway, let's just add .theme to it
Previously, both fish.pc and libfish had generating the
FISH-BUILD-VERSION-FILE attached as a command. In principle they could
both try to run the command simultaneously and now CMake complains about
this with the Xcode generator.
Switch to having fish.pc depend on the CHECK-FISH-BUILD-VERSION-FILE as a
target instead of a command. This allows it to participate in dependency
resolution and CMake will succeed again.
Fixes#7838
When executing “make test -jX” (with X > 1) to build and run tests in a
build directory, there is a race condition between the
serial_test_low_level target and the test_prep target (a dependency of
serial_test_fishscript and serial_test_interactive).
As far as I can tell, these events happen in a serial build scenario
(“make test” with the “Unix Makefiles” CMake generator):
1. The fish_tests binary is built and executed.
2. The test_prep target (a dependency of serial_test_fishscript)
cleans up test directories.
3. Tests in test.fish are executed.
In a parallel build scenario, this often happens:
1. Build of the fish_tests binary is started.
2. The test_prep target cleans up test directories.
3. Build of the fish_tests binary is finished.
4. Execution of the fish_tests binary starts.
5. Execution of the fish_tests binary finishes.
6. Tests in test.fish are executed.
However, if building the fish_tests binary is fast enough but not
instant (e.g. when using ccache), this can happen:
1. Build of the fish_tests binary is started.
2. Build of the fish_tests binary is finished.
3. Execution of the fish_tests binary starts.
4. The test_prep target cleans up test directories.
5. fish_tests tests that depend on said test directories may,
depending on timing, fail because they are wiped by test_prep.
Fix this by making test_prep a dependency of serial_test_low_level so
that test_prep can’t interfere with fish_tests execution.
The only thing we know ever triggered this is old macOS versions,
there's no need to use it for everyone else.
Since this uses try_run it breaks when cross-compiling, which
shouldn't be a common thing on macOS.
Fixes#7737
This is far preferable to the per-test XDG overrides that we may or may
not remember to add the next time around.
Also rename all the directories so it is clear via which variable a file
made its way into that path.
This was a typo. CMake doesn't take comma-separated arguments, but if
you do add the comma it tends to work, because it just takes that
comma as part of the string. So if it takes a directory to work in,
that it will then create, and you pass
${CMAKE_CURRENT_BINARY_DIR},
well, that might just create a "build," directory.
fish wants to build with -mmacosx-version-min=10.9. This is important
because it ensures that we do not use functions or linker features which
which are not available on 10.9. However this collides with the fact
that fish also prefers to use a pcre2 package installed on the system,
which is typically built for that system.
Mac ld will (rightly) complain when it sees a 10.9-targeted binary
linking a 10.15-targeted dylib. This is an annoying warning that gets
emitted on every build.
We could fix this either having Mac builds prefer the vendored PCRE2
by default, or by having debug builds target the system version. But
we want to continue to default to system PCRE2 and we don't want to risk
losing compatibility with older Mac versions. So we will just suppress
all linker warnings in Mac debug builds.
It's not entirely clear why the existing check does not work, but it seems to pass on clang++ even without -latomic, but causes the fish build to fail later.
Confirmed that with this change, g++ does not use -latomic, while clang++ does, and fish builds fine with both.
When CMake's own curses logic fails to find curses/ncurses, we fall back to
pkg-config and manually link the required libraries. Some platforms (RHEL 6,
see #6587) require CURSES_EXTRA_LIBRARY=tinfo, so we link against libtinfo
if it's found but are happy to continue without it if it doesn't exist.
Closes#6587
This adds a new interactive test framework based on Python's pexpect. This
is intended to supplant the TCL expect-based tests.
New tests go in `tests/pexpects/`. As a proof-of-concept, the
pipeline.expect test and the (gnarly) bind.expect test are ported to the
new framework.
