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.
