* Makefile: all: only depend on cmake-build
Previously `make` would first run `cmake-build` (`make` in `build/`),
and then run `make -C build awesome` afterwards again (which gets built
by the first step already).
* Makefile: get rid of cmake-build
* Travis: testing previous commits: make distclean
Otherwise it might fail due to permission errors for existing files:
https://travis-ci.org/awesomeWM/awesome/jobs/476612117#L2785
-- Build files have been written to: /home/travis/build/awesomeWM/awesome/build
[ 1%] Generating manpages/man1/awesome.1
[ 2%] Generating manpages/man1/awesome.1.gz
/bin/sh: 1: cannot create /home/travis/build/awesomeWM/awesome/build/manpages/man1/awesome.1.gz: Permission denied
make[3]: *** [manpages/man1/awesome.1.gz] Error 2
make[2]: *** [CMakeFiles/man.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [cmake-build] Error 2
This makes sense in general (every check target should get its own
flag), and might help with tracking down unexpected coverage changes
(although those appear to be related to the C code only (gcov)).
Just configure `check-unit` to use `--coverage` with `busted` with
`DO_COVERAGE=1`.
I got confused why `check-unit` would not generate coverage.
This keeps it in line with other targets that generate coverage when
used with the same name.
Instead of printing the list of commits for which tests failed, this
printed all commits.
Testing done on this change: None. Testing the infrastructure for Travis
is a bit hard and quite meta. (Tests for the tests?)
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is not really a test. It just starts xeyes and sees if anything
explodes.
However, the reason for this test is to stabilise code coverage.
Apparently, Gtk(?) sometimes creates shaped windows. This had the effect
that codecov always reports random changes to code coverage, depending
on if this specific test run saw any shaped client windows or not.
Thus, by explicitly adding a test that runs a shaped client, hopefully
these random fluctuations disappear.
Hopefully-fixes: https://github.com/awesomeWM/awesome/issues/1975
Signed-off-by: Uli Schlachter <psychon@znc.in>
- install luacov.runner in tests/_runner.lua.
- use Lua's `dofile` to execute the test files, which will give us
coverage for them.
- CMakeLists.txt: revert DO_COVERAGE env injection
- revert cd: make f absolute if not in source_dir
It might be well known that test-menubar.lua fails with "cannot do calls
on non-normal thread" when run under our Lua 5.3 build with coverage
tracking enabled. This new, extra assertion catches the error earlier
and in a different way. Since more assertions means more errors caught,
let's add this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
codecov-bash runs it by default already, therefore we do not not have to
do so manually before do_codecov_gcov.
And with `do_codecov` itself, it gets disabled using `-X gcov`.
Using exit code != 1 (e.g. 2 as with "make") appears to cause Travis to
consider the build job as an error ("!"), instead of a failure ("X").
Example build: https://travis-ci.org/awesomeWM/awesome/builds/248484247
!: https://travis-ci.org/awesomeWM/awesome/jobs/248484252
Test finished successfully
There were 3 errors!
make[4]: *** [CMakeFiles/check-integration] Error 1
make[3]: *** [CMakeFiles/check-integration.dir/all] Error 2
make[2]: *** [CMakeFiles/check-integration.dir/rule] Error 2
make[1]: *** [check-integration] Error 2
make: *** [check-integration] Error 2
++return
X: https://travis-ci.org/awesomeWM/awesome/jobs/248484250
Test finished successfully
There were 3 errors!
The combination of TEST_PREV_COMMITS=1 and EMPTY_THEME_WHILE_LOADING=1
does not work. When trying to test the previous commits, the following
error happens:
error: Your local changes to the following files would be overwritten by
checkout:
lib/beautiful/init.lua
This local modification was done by EMPTY_THEME_WHILE_LOADING=1.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes sure that the liblua.so that we built actually depends on the
libraries that it needs (libm and libdl). Previously we already tried
this, but specified "-ldl" at the beginning of the command line. Since
nothing needed this library yet, the linker just ignored it.
Signed-off-by: Uli Schlachter <psychon@znc.in>
ldoc was not installed for the DO_CHECKQA build.
This merges it with the BUILD_APIDOC build job, which is one of the
faster ones; installing ldoc into the DO_COVERAGE=coveralls would slow
that one down a lot.
This also moves the two slowest builds (with coverage reporting) to the
top, so they get started first.
Fixes https://github.com/awesomeWM/awesome/issues/1710.
Closes https://github.com/awesomeWM/awesome/pull/1716.
The entry "gtk+3.0" caused the following to happen:
Note, selecting 'libcanberra-gtk3-0-dbg' for regex 'gtk+3.0'
Note, selecting 'monodoc-gtk3.0-manual' for regex 'gtk+3.0'
Note, selecting 'libgtk3.0-cil' for regex 'gtk+3.0'
Note, selecting 'libavahi-ui-gtk3-0' for regex 'gtk+3.0'
Note, selecting 'libwxgtk3.0-0-dbg' for regex 'gtk+3.0'
Note, selecting 'libseed-gtk3-0' for regex 'gtk+3.0'
Note, selecting 'libgtk3.0-cil-dev' for regex 'gtk+3.0'
Note, selecting 'libcanberra-gtk3-0' for regex 'gtk+3.0'
Note, selecting 'libinfgtk3-0.5-0' for regex 'gtk+3.0'
Note, selecting 'libwxgtk3.0-0' for regex 'gtk+3.0'
Note, selecting 'gir1.2-dbusmenu-gtk3-0.4' for regex 'gtk+3.0'
Note, selecting 'libwxgtk3.0-dev' for regex 'gtk+3.0'
This was clearly not intended. Fix this by using gir1.2-gtk-3.0 instead,
which is what we actually want (GObject introspection data for GTK 3).
This pretty much reverts commit 30a527fcfd.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Move table functions out of awful.util into new gears.table
* travis: Use v9999 prefix for full requests
Make sure no newly deprecated functions are used
* Move all `awful.util.table.*` calls to `gears.table.*` calls
Move table test functions from awful/util_spec to new gears/table_spec
Change awful.util.subsets call to gears.math.subsets in awful/key.lua
For loading a theme, beautiful.init() has to be called. We do not handle
dynamic changes of the theme, so if the theme is changed after something
was already queried, this change will not apply. This also means that
before the theme is loaded, nothing useful can be returned. In fact,
code that tries to access the theme during require() will never get a
useful value from beautiful, but just nils.
To catch this, one Travis build is modified so that an error is raised
if the theme is accessed before beautiful.init() was called.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Currently, "everything can require everything". It's an unstructured
mess which sometimes causes problems.
This commit adds a tool that enforces a white-list of require() uses. It
uses depgraph to scan the source code and then each use of require()
that is found is checked. If any violations are found, the tool returns
a failure.
This tool is wired up to a new target "make check-requires" which is
included in "make check". Thus, Travis will run this.
Reference: https://github.com/awesomeWM/awesome/issues/1400
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Daniel Hahler
Uli Schlachter
Uli Schlachter
Joseph Herlant
Reiner Herrmann
Daniel Hahler
actionless
Kevin Zander