* 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.
Before this commit, it was added by `wibox.widget.base` if
`:setup()` is used. However it doesn't work for the `awful.popup`
because of the extra indirection.
This commit stops the monkey-patching and make sure the function
always exists. This doesn't prevent it from not working and in
the long run this should still be moved into the hierarchy.
However for now it makes the situation a lot more consistent and is a
quick band-aid without too much controversy.
Mitigate #2181
Given they are all small, it makes more sense to just merge them like
we did for the client API
For some reasons GTK doesn't want to be merged. To be investigated.
Given noone understand this code, this will prevent some semi likely
regressions from going unnoticed. The main risk is the shims not
producing the exact same results as the real implementation and
cause different code paths to be taken.
As of this commit, both the "real" and "shim" implementation were given
the same set of tests with print() at every step of next_to. The
resulting log was then checksummed to ensure both are identical.
It also add some properties such as `border_width`, `border_color`
and `preferred_alignments`.
It also fix a documentation bug where the `margin_topleft` was called
`margins_topleft`. To conform to the documentation, both are now valid
but one should be removed the next time the API changes.
Fixes#1978
By passing the geometry, important information used by
awful.placement.next_to were "lost". Given `next_to` supports both
widget position, the mouse and client/wibox relative positioning, it
has to know the object type.
Daniel Hahler
Daniel Hahler
Aire-One
mergify[bot]
Emmanuel Lepage Vallee
actionless
glenvt18
ArenaL5