Some of these were failing on Travis quite often, and this is probably
the result of too tight a window.
E.g. one emacs test (transpose words, default timeout, short delay)
waited 250ms to enter something else, with a timeout of 300ms. That
meant a window of 50ms.
* [PO][FR]fix translation
"key" was being translated to "fonction". ("function")
Based the new wording on the above translation.
* [PO][FR]fix translation
"directory" was being translated to "fonction". ("function")
* [PO][FR]fix translation
"Permission denied" was being translated to "Nom de fonction illégal". ("Illegal function name")
I took the new translation from strerror.
* [PO][FR]fix translation
"Introduction" was being translated to "Instruction illégale". ("illegal instruction")
* $ make po/fr.po
* #4655: changes requested by @PenegalECI
* fix some automatically generated translations
uniformly translate "logging" to "journalisation".
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.
Some dotfile users like to add directories to PATH that point at
non-existent directories (because those directories exist on other
machines). Stop warning in that case, unless those directories contain
a colon, in which case it's probably a user error.
Changed cd completion to differentiate between cd autosuggest and cd tab
completion. cd autosuggest will find deepest unique hierarchy and cd tab
completion will not.
Issue #4402
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
If `doxygen` isn't installed, the man files aren't built and that's
quite ok. The cmake `install` target was presuming the man files would
always be present and the install stage was failing if they weren't
built.
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
`git push REMOTE :BRANCH` deletes remote branch BRANCH from remote
REMOTE. Should only kick in when the pattern matches, hopefully didn't
break anything else!
