Install the icon of the application in the hicolor XDG icon theme;
this way it can be properly loaded by XDG menus in the currently set
XDG icon theme, without looking in the legacy pixmaps location.
This avoids generating the tags files all the time, and makes `make
install` with `CMAKE_INSTALL_MESSAGE=LAZY` much more silent in general.
Using `copy_if_different` instead of `remove` + `copy_directory` might
be good on top, but is a) not really necessary anymore and b) would not
sync removed files.
For this `file(COPY` could be used, but would require to re-run cmake on
changed input files then.
Only remove the directory contents. If the directory itself is removed,
then `sudo make install` creates a root-owned …/doc/ directory. That
breaks the next non-root build.
This was an accident of 0b1904d835.
Note: the following does not work, because it misses renamed help files
(which would no longer be in the build-tree definition)
COMMAND ${CMAKE_COMMAND} -E remove ${BUILDDOCFILES} ${GENERATED_HELP_TAGS}
With `xdg-*` utilities CMAKE_INSTALL_PREFIX is incorrectly ignored.
Taken from [nvim-qt][1]. For some reason it only checks for !APPLE.
[1]: b26596d164/src/gui/CMakeLists.txt (L48-L55)
Closes#3689
cmake: Add `desktop-install` and `icon-install` targets. `runtime`
target will trigger them.
Specification:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys
Icons are stored system-wide in /usr/share/applications or user wide at
/usr/share/icons/hicolor/scalable/apps and can be overriden in ~/.local/share/icons
nvim.desktop file can be installed system wide or in
~/.local/share/applications/
To test without an installer:
$ xdg-desktop-menu install --novendor runtime/nvim.desktop
$ xdg-icon-resource install --novendor --mode user --size 64 contrib/nvim-icon.png
Once it is installed, you can test with gtk-launch if installed or
dmenu/rofi (drun mode)
This was more trouble than it is worth:
- remove_directory fails if doc/ is not owned by the user
- some devs build in-tree, then deleting doc/ breaks the build
- `make install` isn't affected by the stale files at all: the tags are
built before install-time
So, reverting this change means only that devs who use a build/
directory will need to delete build/runtime/doc/ on the occasion that we
rename a doc file.
If a help file is renamed, stale help files in the build workspace will
cause duplicate tags (which causes the build to fail). To avoid this,
always delete build/runtime/doc/ before building helptags.
Specify that the ${GENERATED_HELP_TAGS} "command" (output) depends on
`helptags` so that it always regenerates the doc/ tags. (cmake "targets"
always run, whereas "commands" are contingent on their dependencies. But
we don't define doc/ dependencies because they are circular.)
Declare dependency in terms of directory, rather than individual doc
files to avoid target dependency cycles. This still maintains install
targets at doc file level.
I see that problem fixed by #2801 was resurrected by making help tags file
generated in a more direct way. This fixes the hang without using the empty
file.
