topic_monitor allows for querying changes posted to one or more topics,
initially sigchld. This will eventually replace the waitpid logic in
process_mark_finished_children().
Comment from the new header:
Topic monitoring support. Topics are conceptually "a thing that can
happen." For example, delivery of a SIGINT, a child process exits, etc. It
is possible to post to a topic, which means that that thing happened.
Associated with each topic is a current generation, which is a 64 bit
value. When you query a topic, you get back a generation. If on the next
query the generation has increased, then it indicates someone posted to
the topic.
For example, if you are monitoring a child process, you can query the
sigchld topic. If it has increased since your last query, it is possible
that your child process has exited.
Topic postings may be coalesced. That is there may be two posts to a given
topic, yet the generation only increases by 1. The only guarantee is that
after a topic post, the current generation value is larger than any value
previously queried.
Tying this all together is the topic_monitor_t. This provides the current
topic generations, and also provides the ability to perform a blocking
wait for any topic to change in a particular topic set. This is the real
power of topics: you can wait for a sigchld signal OR a thread exit.
This represents a "resolved" io_chain_t, where all of the different io_data_t
types have been reduced to a sequence of dup2() and close(). This will
eliminate a lot of the logic duplication around posix_spawn vs fork, and pave
the way for in-process redirections.
This represents a "resolved" io_chain_t, where all of the different io_data_t
types have been reduced to a sequence of dup2() and close(). This will
eliminate a lot of the logic duplication around posix_spawn vs fork, and pave
the way for in-process redirections.
Since fish began resolving symlinks it broke the running-from-build-dir
detection in fish.cpp if the build directory were a symlink (which is
common on some platforms where the default user HOME directory is a
symlink in the first place, e.g. FreeBSD).
Load fish docs and configuration out of the source and/or build
directories rather from the installed paths when running directly out
of the cmake build directory.
Closes#5255.
Default to RelWithDebInfo (-O2 -g) if no custom CMAKE_BUILD_TYPE is
defined. Also add flags for use with CMAKE_BUILD_TYPEs Debug, Release,
and RelWithDebInfo.
This introduces a new type features_t that exposes feature flags. The intent
is to allow a deprecation/incremental adoption path. This is not a general
purpose configuration mechanism, but instead allows for compatibility during
the transition as features are added/removed.
Each feature has a user-presentable short name and a short description. Their
values are tracked in a struct features_t.
We start with one feature stderr_nocaret, but it's not hooked up yet.
* Make wcwidth configurable
This adds the cmake option "INTERNAL_WCWIDTH" (to be set to "ON" or
"OFF") and the configure option --[en,dis]able-internal-wcwidth.
Both default to enabling our fallback, but can be set to use the system's wcwidth again.
Sequel to #4554.
See #4571, #4539, #4609.
On my system, this would fix#4306.
This reverts commit 36a2f2cc01.
This attempted to modify RPATH when building with Ninja, but the CMake if
statement wasn't actually valid so this wasn't doing anything. This check
couldn't really be tested - let's make sure not to accumulate build system
rules that we don't understand.
This untangles the CMake versioning issues (I hope) as discussed in #4626.
Note most of the advice found on the Internet about how to inject git
versions into CMake is just wrong.
The behavior we want is to unconditionally run the script
build_tools/git_version_gen.sh at build time (i.e. when you invoke ninja or
make, and not when you invoke cmake, which is build system generation time).
This script is careful to only update the FISH-BUILD-VERSION-FILE if the
contents have changed, to avoid spurious rebuilding dependencies of
FISH-BUILD-VERSION-FILE. Assuming the git version hasn't changed, the script
will run, but not update FISH-BUILD-VERSION-FILE, and therefore
fish_version.o will not have to be rebuilt.
This might normally rebuild more than is necessary even if the timestamp is
not updated, because ninja computes the dependency chain ahead of time. But
Ninja also supports the 'restat' option for just this case, and CMake is rad
and exposes this via BYPRODUCTS. So mark FISH-BUILD-VERSION-FILE as a
byproduct and make the script always update a dummy file
(fish-build-version-witness.txt). Note this is the use case for which
BYPRODUCTS is designed.
We also have fish_version.cpp #include "FISH-BUILD-VERSION-FILE", and do a
semi-silly thing and make FISH-BUILD-VERSION-FILE valid C++ (so there's just
one version file). This means we have to filter out the quotes in other
cases..
This reverts commit 25839b8c36.
This was an attempt to simplify the version generation, but it
computed the version at build sytem generation time rather than
at build time, requiring another run of CMake to update it.
Correctly generate FISH_BUILD_VERSION for use in fish_version.h/cpp and
fish.pc to allow `fish --version` and `echo $version` to work again.
Not needing the same convoluted measures used by Makefile builds to
prevent the regeneration of the fish version file when it hasn't
changed.
Purposely created a new `cmake_git_version_gen.sh` file so that the old
`git_version_gen.sh` remains compatible with the existing Makefile build
script. Same reason why `fish.pc.in` was not modified to use a lowercase
variable name to match the CMAKE variable of the same name.
Closes#4626
CMake originally links build artifacts/results so that they can run from
the target directory. As a result, it must first relink the binaries
before installation so that they can run from the installation target
directory, typically done in the preinstall stage. Ninja does not have a
preinstall stage, and the CMake code that generates the build.ninja file
does not take that into account [0].
Setting `CMAKE_BUILD_WITH_INSTALL_RPATH` [1] makes it originally link
the files with the RPATH settings for the final destination directory,
meaning that relinking is no longer needed.
Technically setting the RPATH is not required for the `fish` binary as
we do not have any relative dependencies; this is the output of
`ldd ./build/fish`:
```
linux-vdso.so.1 => (0x00007ffffacdc000)
libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5
(0x00007f6632350000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
(0x00007f6632120000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
(0x00007f6631f00000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f6631b70000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
(0x00007f6631860000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f6631630000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f6631410000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
(0x00007f6631040000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6632600000)
```
However, since the bug only exists when the build generator is set to
ninja, the workaround is only activated for that specific build
generator to prevent any future problems.
[0]: https://cmake.org/Bug/print_bug_page.php?bug_id=13934
[1]: https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html
This adds a new library fishlib, which the CMake build builds.
This library is linked by the tests, fish, and fish_indent, so
that object files do not have to be built separately for each
of them.
This adds support for creating the FISH-BUILD-VERSION-FILE in the CMake
build. A FISH-BUILD-VERSION-FILE is created in the CMake directory
and only updated when necessary.
This adds a new script build_tools/build_lexicon_filter.sh
that builds the lexicon filter. It is factored out from the Makefile,
and both the Makefile and CMake build invoke it.
