$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.
fish's cmake install routines were attempting to create system
directories that already existed, an operation for which the permissions
to do so may not be available (e.g. /usr/local/share/pkgconfig)
This commit first checks if a directory exists before creating it.
Homebrew and other systems set the path for the extra completion,
function and configuration directories outside the writeable prefix.
Mirror the autotools build in trying to create these directories, but
not causing the whole install to fail if this operation in unsuccessful.
The custom command for fish.pc had a dependency on FBVF, but it appears
that the relative path to FBVF was incorrect and with CMake 3.10.1 under
FreeBSD this was consistently causing the build to fail if
../build_tools/git_version_gen.sh hadn't (coincidentally, I think?)
already run.
Explicitly set the dependency path for FBVF to the binary directory.
The custom command for fish.pc had a dependency on FBVF, but there was
no cmake rule for the generation of the FBVF file. With CMake 3.10.1
under FreeBSD, this was consistently causing the build to fail if
../build_tools/git_version_gen.sh hadn't (coincidentally, I think?)
already run.
`-v` is a non-standard GNU-only extension to `awk`, its usage in the
generation of the fish.pc script breaks on non-GNU platforms (such as
FreeBSD and presumably macOS).
Using `sed` with only standard posix commands instead.
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.
