Include dwmipcpp as a library in cmake and config files, so it can be built
automatically. The configuration of dwmicpp was added to match that of i3 and
bspwm to maintain the same cmake workflow and style.
* 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
I don't know the original intention behind this but it clutters up debug
traces and basically makes ccache useless.
The only benefit it has, giving version info in stacktraces, is kind of
void since we already ask for version information on github issues.
We need to have the version string available in multiple places not just
the source code. It is now hardcoded in the root CMakeLists.txt and all
files that need it will be configured with cmake.
This also removed the unecessary duality of GIT_TAG and APP_VERSION and
GIT_TAG_NAMESPACE and APP_VERSION_NAMESPACE.
* 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
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/
googletest (gtest) is more feature rich than the current implementation
which only provides expect() which is basically an assertion. It is also
quite intuitive to use, this can be seen in the rewrite of the
command_line test where EXPECT_THROW replaces a whole try-catch block.
I have also moved the source files the test depend on to be linked in
CMakeLists.txt instead of including them directly because include .cpp
files is bad.
The two x11 tests were removed because they were written two years ago
and a lot of the things they depend on, don't actually exist anymore in
polybar (I think we switched to xpp after those tests were written)
Tests are now compiled with the gcov lib which can be used to provide
test coverage in a second step
