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
install_xcb_xrm.sh takes advantage of the travis cache but it doesn't
actually install the libraries on the system when it finds that the
compilation has been cached.
Using brace initialization here causes bar.hpp to not compile when
included on its own, forcing all clients to also include
tray_manager.hpp and so on, which defeats the purpose of forward
declaring those classes.
This also allows us to remove the tray_manager.hpp, renderer.hpp and
parser.hpp includes from the clients of bar.hpp
As mentioned in #1215, gcc >=8 will complain, if strncpy truncates the
source string or gcc can prove there is no NUL terminating byte.
This also updates the i3ipcpp submodule where there was a similar error
Fixes#1215
atoi, atof and so on have undefined behavior if anything goes wrong. We
now use strto*, but without error checking. In most places overflows and
the like *should* not happen. String to number conversions are only used
when reading data from other applications or from the config, if another
application gives unparsable strings or too large numbers, then most
likely there is something wrong with that application. If the error
comes from the user config, then the user has to live with values
provided by strto* on error (which are very reasonable)
Fixes#1201
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
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
This is basically a major rewrite of the .ycm_extra_conf.py file that
ycm uses to determine what compile commands it should use for a file.
But the basic purpose is for it to use the generated flags in
build/compile_commands.json that is generated by cmake for as many files
as possible.
Before it always used the hardcoded default flags which would not always
work for all files.
Now it gets the proper flags for all files I tested.
In the src and tests folder the flags are already generated by cmake
In the include folder it tries to use the flags of the corresponding
source files in the src folder
