As mentioned in
https://github.com/fish-shell/fish-shell/issues/11921#issuecomment-3540587001,
binaries duplicate a lot of information unnecessarily.
$ cargo b --release
$ du -h target/release/fish{,_indent,_key_reader}
15M target/release/fish
15M target/release/fish_indent
4.1M target/release/fish_key_reader
34M total
Remove the duplication in CMake-installed builds by creating hard
links. I'm not sure how to do that for Cargo binaries yet (can we
write a portable wrapper script)?
This is still a bit weird because hardlinks are rarely used like
this; but symlinks may cause issues on MSYS2. Maybe we should write
a /bin/sh wrapper script instead.
This completely removes our runtime dependency on gettext. As a
replacement, we have our own code for runtime localization in
`src/wutil/gettext.rs`. It considers the relevant locale variables to
decide which message catalogs to take localizations from. The use of
locale variables is mostly the same as in gettext, with the notable
exception that we do not support "default dialects". If `LANGUAGE=ll` is
set and we don't have a `ll` catalog but a `ll_CC` catalog, we will use
the catalog with the country code suffix. If multiple such catalogs
exist, we use an arbitrary one. (At the moment we have at most one
catalog per language, so this is not particularly relevant.)
By using an `EnvStack` to pass variables to gettext at runtime, we now
respect locale variables which are not exported.
For early output, we don't have an `EnvStack` to pass, so we add an
initialization function which constructs an `EnvStack` containing the
relevant locale variables from the corresponding Environment variables.
Treat `LANGUAGE` as path variable. This add automatic colon-splitting.
The sourcing of catalogs is completely reworked. Instead of looking for
MO files at runtime, we create catalogs as Rust maps at build time, by
converting PO files into MO data, which is not stored, but immediately
parsed to extract the mappings. From the mappings, we create Rust source
code as a build artifact, which is then macro-included in the crate's
library, i.e. `crates/gettext-maps/src/lib.rs`. The code in
`src/wutil/gettext.rs` includes the message catalogs from this library,
resulting in the message catalogs being built into the executable.
The `localize-messages` feature can now be used to control whether to
build with gettext support. By default, it is enabled. If `msgfmt` is
not available at build time, and `gettext` is enabled, a warning will be
emitted and fish is built with gettext support, but without any message
catalogs, so localization will not work then.
As a performance optimization, for each language we cache a separate
Rust source file containing its catalog as a map. This allows us to
reuse parsing results if the corresponding PO files have not changed
since we cached the parsing result.
Note that this approach does not eliminate our build-time dependency on
gettext. The process for generating PO files (which uses `msguniq` and
`msgmerge`) is unchanged, and we still need `msgfmt` to translate from
PO to MO. We could parse PO files directly, but these are significantly
more complex to parse, so we use `msgfmt` to do it for us and parse the
resulting MO data.
Advantages of the new approach:
- We have no runtime dependency on gettext anymore.
- The implementation has the same behavior everywhere.
- Our implementation is significantly simpler than GNU gettext.
- We can have localization in cargo-only builds by embedding
localizations into the code.
Previously, localization in such builds could only work reliably as
long as the binary was not moved from the build directory.
- We no longer have to take care of building and installing MO files in
build systems; everything we need for localization to work happens
automatically when building fish.
- Reduced overhead when disabling localization, both in compilation time
and binary size.
Disadvantages of this approach:
- Our own runtime implementation of gettext needs to be maintained.
- The implementation has a more limited feature set (but I don't think
it lacks any features which have been in use by fish).
Part of #11726Closes#11583Closes#11725Closes#11683
Not sure about whether "man fish-terminal-compatibility"; it's not
really meant for end-users, but it also doesn't hurt raise awareness
of the existence of this doc.
Either way, we should be consistent with embedded builds, where this
works since the parent commit.
fish adds ~/.local/share/fish/man to its MANPATH for builtins etc. But pages
like fish-doc are unambiguous so it seems like they should be accessible
from outside fish by default.
Closes#10711
We are no longer C++, we no longer support xcode
Note: This will remove a warning "DO NOT EDIT" comment from __fish_build_paths.fish, but
that's unnecessary. The file is typically in /usr or another
package-manager-owned location, so people don't typically edit it.
And if it did we don't actually *care*, it'll work fine.
Use Rust for executables
Drops the C++ entry points and restructures the Rust package into a
library and three binary crates.
Renames the fish-rust package to fish.
At least on Ubuntu, "fish_indent" is built before "fish".
Make sure export CURSES_LIBRARY_LIST to all binaries to make sure
that "cached-curses-libnames" is populated.
Closes#10198
GNUInstallDirs is what defines CMAKE_INSTALL_FULL_BINDIR and such, so
the setting in Rust.cmake didn't work.
This also makes build.rs error out if any of these aren't defined
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.
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
This allows all variables to be set properly when the prefix or datadir changes.
The generated .pc file looks like this:
prefix=/usr/local
datadir=${prefix}/share
completionsdir=${datadir}/fish/vendor_completions.d
functionsdir=${datadir}/fish/vendor_functions.d
confdir=${datadir}/fish/vendor_conf.d
Name: fish
Description: fish, the friendly interactive shell
URL: https://fishshell.com/
Version: 3.1.0-402-g75ae172ba228-dirty
Closes: https://bugs.archlinux.org/task/65904
$XDG_DATA_DIRS/vendor_{completions,conf,functions}.d
Additionally, CMake variables extra_{completions,conf,functions}dir are
appended, if they are not already contained in $XDG_DATA_DIRS.
If XDG_DATA_DIRS is not defined, we fall back to
$__fish_datadir/vendor_completions.d:${extra_completionsdir}
for completions. Same for conf and functions.
Reverts 71329a250b.
That tried to fix problems with pkgconfig by not recreating it.
Instead, use the function we already have for not trying too hard to
create a directory.
Fixes#5735.
