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`.
The clangformat target updates all files in-place while the
clangformat-dryrun target prints an error message for each format-change
clang-format would apply.
The latter exits with a non-zero error code if there are any changes.
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
Whenever a release is published, this action will create a release
archive and update the release body with a download section.
This also integrates the suggestions from #2276Resolves#2276
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.
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.
Simplifies the building and running of tests
Also exports the proper env variables so that the googletest output is
colored
ctest can use env variables for some of its options so we can for
example run
CTEST_PROGRESS_OUTPUT=1 make check
to run ctest with the --progress flag
This also makes the travis test.sh script obsolete
This travis environment contains more up-to-date versions of clang and
gcc (namely 7.0.0 and 5.4.0). This allows us to remove all the code used
to get those newer versions in trusty.
Ref: https://docs.travis-ci.com/user/reference/xenial/
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
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.
