Commit ac8af66005 added beautiful.theme_path, which is used to save the
directory that contains the theme file that was loaded. Just two months
later, commit ca12473584 broke this code by adding a __newindex
metamethod. This caused the assignment to beautiful.theme_path to be
redirected to the theme. However, the theme is immediately replaced by
beautiful.init() after setting up the theme_path, so this assignment got
lost.
Fix this by using rawset() to bypass the metamethod.
Fixes: https://github.com/awesomeWM/awesome/issues/2573
Signed-off-by: Uli Schlachter <psychon@znc.in>
* 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
* cmake: use add_custom_target/add_dependencies instead of CHECK_TARGETS
This makes it fail in case of errors explicitly. Previously appending
to CHECK_TARGETS in tests/examples/CMakeLists.txt was silently ignored.
* cmake: check: depend on check-unit always
Without busted this will print a message only, but that is good to have.
(I was confused why "check" would not depend on "check-unit" when
looking at the generated Makefile (which was caused due to some luarocks
environment being active without busted))
`awesome-client 'return 1' 'return 2'` would only run the first command.
This also fixes other issues reported by shellcheck, and uses `read`
directly to allow `shellcheck` to parse that construct correctly.
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.
Sorky
mergify[bot]
Kevin Zander
Sorky
Daniel Hahler
Uli Schlachter
Emmanuel Lepage Vallée
Daniel Hahler
Aire-One