* 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
They're not really any different from the release builds and only
elongate the build process. Also now that we have a minimal build, we
would have more than five build configurations which would make travis
limit itself to five concurrent builds, letting the last build wait on
the others.
Also it's just unnecessary load on the travis servers
Uses none of the optional dependencies. This ensures that polybar can
build without any of the supposedly optional dependencies. This would
have detected the cause of the xrm build failure before it was merged
This allows use to pick and choose apt packages for each of our build
configurations
This makes the definition of a new build configuration more verbose but
it gives us greater flexibility and it's also a preparation for a new
build configuration with minimal number of packages
The PYTHONPATH env variable needed to be removed because it was messing
with pip and cpp-coveralls
Unfortunately adding the '-e build' to coveralls doesn't work to exclude
source files in the build directory, as it won't collect any data then.
If at some point, we have source files that are used by the tests
somewhere inside the build folder that isn't covered by the exclusion
rules, we'll need to add it here
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
