Each major target of polybar can now be enabled/disabled while
configuring (even polybar itself).
The cmake code specific to each target will only run if the target is
enabled.
This allows us to for example just build the documentation without
having to run all the cmake code related to compilation or having the
polybar dependencies installed (other than sphinx).
They were required before, but could technically be deactived (the
compilation would fail, but configuration was possible).
The WITH_XRANDR and WITH_XCOMPOSITE now no longer appear in the cmake
part. It still appears in the source code, but is always set to 1
Fixes#1536
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.
* 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
Whenever a new gcc version is released that introduces new warnings,
this breaks lots of builds on the user's side. This change pushes the
detection of these new warnings a bit back until either a user reports
warnings or developers get the new compiler updates. I think this is a
good tradeoff since release builds are no longer totally broken as soon
as a new compiler version comes out.
Travis still uses -Werror because there we actually want builds to fail.
The polybar executable with RelWithDebInfo gets over 100MB. And there
really isn't any reason to have users install such huge executables.
Release build type gives you approx. 3.6M executables
Fixes#1497
As the kernel documentation said:
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight
This file will also show the brightness level stored in the driver, which may not be the actual brightness (see actual_brightness).
Therefore the brightness value should be read in the actual_brightness file.
Fix#1180
* Clean up CMake logic
- removed logic to find CppUnit (no longer used)
- removed "dirs" variable used to pass include directories
- removed add_library function (no longer used)
- removed make_executable function
* only used in 2 places (polybar and polybar-msg)
* it was more general than needed, logic is simpler without it
- split polybar into static library and executable
* this allows linking unit tests to the library
* rename library
* add coverage build
- Added a CMake build type "Coverage" that builds C and C++
code with the "--coverage" flag (recognized by both GCC and Clang)
- removed "-Wno-missing-field-initializers" from test flags,
since it didn't seem to be needed any more
- removed logic from tests/CMakeLists to disable "-Werror" and "-pedantic-errors"
since there didn't seem to be any warnings during the build
* fix whitespace
* update travis
* remove O2 from defalt flags
* allow tests to be built by default make target
* disable Werror for debug builds
This patch enables support for nl80211. In case the libnl-genl-3.0
library isn't found, it will fall back to Wext instead.
The library to use can also be manually set with the CMake option
WITH_LIBNL.
The Wireless-Extensions (WE or Wext) are deprecated and long replaced
by cfg80211.
Although Wext isn't used by WiFi drivers anymore, CFG80211_WEXT allows
old tools to communicate with modern drivers by providing a wrapper
API.
The only reason polybar couldn't build without xkb is because the
xkeyboard module's source file was not removed during compilation.
xkeyboard already has an entry in unsupported.hpp
This effectively makes xcb-util-xkb optional
Following [1] to get to this setup.
We setup all the ccache configuration before calling project() because
project will perform compiler checks. This is also why we can't use
message_colored here and print the colors manually
Before ENABLE_CCACHE was not yet defined when we reached the check in
01-core because the option was defined in 02-opts
[1] https://crascit.com/2016/04/09/using-ccache-with-cmake/
Before, because of [ -d "$search" ] || search="$(dirname "$search")",
clang-format.sh would search for files to format in the whole repo
(even in the build directory and the submodules)
This now also looks for source files in the tests folder
I have removed the clang-format from clang-tidy.sh because one may want
to run clang-tidy without reformatting
Makes helping with build issues easier as we readily see what versions
are being used.
Cmake already prints the version but only when run the first time and
not on subsequent calls, so the information is often lost
