Search for xcbgen with PYTHON_EXECUTABLE
This way users can specify `-D:PYTHON_EXECUTABLE` to force a certain
python executable and that executable will then also be used to search
for xcbgen.
This should also provide a more universal solution to the configuration
issues with pyenv or conda since the user can just specify
`-D:PYTHON_EXECUTABLE=/usr/bin/python3`.
* Create default config and install to /etc/polybar
Closes#2405
* Search for config in /etc
We search in XDG_CONFIG_DIRS, /etc/xdg, and /etc but only for config.ini
Closes#2016
* Remove config installation from build.sh
* Remove userconfig cmake file
* Cleanup
* Cleanup default config
* Update CHANGELOG.md
Co-authored-by: dvermd <315743+dvermd@users.noreply.github.com>
* Update src/main.cpp
Co-authored-by: dvermd <315743+dvermd@users.noreply.github.com>
* Add tests for string functions
* Support loading bars from fallbacks in /etc
* Combine duplicate string_util::contains test
Co-authored-by: dvermd <315743+dvermd@users.noreply.github.com>
* xpp: Update submodule
* aur: Force system python in polybar-git
This should resolve problems on systems with conda or pyenv enabled that
would otherwise not pick up xcbgen properly
xorgproto always was a make dependency (I think) but it was
automatically included indirectly by another dependency.
Arch recently cleaned up some xorg related packages which made xorgproto
no longer an indirect dependency of polybar which spams cmake with
messages like:
```
Package 'xproto', required by 'xau', not found
Package 'xproto', required by 'xdmcp', not found
Package 'xproto', required by 'xau', not found
Package 'xproto', required by 'xdmcp', not found
Package 'xproto', required by 'xau', not found
Package 'xproto', required by 'xdmcp', not found
Package 'xproto', required by 'xau', not found
Package 'xproto', required by 'xdmcp', not found
```
And during `make` finally completely fails the build because some
library's include directories are not honored because the xproto.pc file
cannot be found:
```
In file included from /home/patrick96/Projects/github.com/patrick96/polybar/include/cairo/utils.hpp:3,
from /home/patrick96/Projects/github.com/patrick96/polybar/src/cairo/utils.cpp:3:
/usr/include/cairo/cairo-ft.h:46:10: fatal error: ft2build.h: No such file or directory
46 | #include <ft2build.h>
| ^~~~~~~~~~~~
```
Ref: https://bugs.archlinux.org/task/64892
The binary is not needed to compile and run polybar with pulseaudio
support. Though of course there is no use in having a pulse module when
you don't have pulseaudio installed.
In the AUR optdepends means that the package can run without optdepends
installed. In polybar most features, if enabled at compile time, cannot
run without their dependencies and will crash polybar. Now the
optdepends only contains truly optional dependencies.
Polybar can run without the i3-wm package because it only relies on the
`i3` executable and is not dynamically linked against any library in i3.
* Use GNUInstallDirs instead of hardcoded paths
This change should be a no-op in the normal case and at the same time make it
easier to customise polybar builds on systems with special needs.
* Avoid creating /usr/share/doc/polybar/polybar/*
* Include GNUInstallDirs for the doc target itself
* cmake: Don't try to set CMAKE_INSTALL_* variables
Since we include GNUInstallDirs all these variables are already set
* cmake: Print install directories in summary
* fix(cmake): Make doc-only work like normal build
This is kind of a dirty hack to force CMAKE_INSTALL_DOCDIR to use
`polybar` as the project name when only polybar-doc is built.
Maybe it is wiser at some point to be able to do a doc only build (and
install) that can be done from the top level project. Then we would also
not need to include GNUInstallDirs here
