Those are most likely deprecation warnings, but the tests should be free
of warnings (from awesome) anyway.
The "Last main loop iteration took X seconds!" warning is filtered out.
This adds a custom command to build the documentation, where you can
specify the generated output then. "ldoc" then depends on this output.
This way "ldoc" is not being run every time, but only if the input files
have changed. ldoc's config is added therefore to the list of
dependencies to make config changes trigger a rebuild.
CMake "fakes" a call to "project(Project C CXX)" if it does not see a
project() call in CMakeLists.txt. Since we had this call in a different
file, this default applied. This meant that CMake unnecessarily required
a C++ compiler.
Fix/work-around this by moving the call to project() into CMakeLists.txt
Reference: https://github.com/awesomeWM/awesome/pull/1907#discussion_r125581273
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes "make install" not run the unit tests (again).
Instead "check-unit" is added to the top-level wrapper Makefile to be
run for its "all" task.
Previously, the lgi check used the normal Lua interpreter to check if
lgi is installed. However, nothing ensures/requires that awesome is
built against the same Lua version as the Lua interpreter. This means
that if lgi is only available for some Lua version, then the check could
succeed even though awesome would later fail to start. Also, the check
might have failed even though awesome would not have any problems
finding lgi.
This commit replaces lgi-check.sh by a small C program which does the
same thing. This ensures that the same Lua version is used as awesome
will be using.
There are some places that still use the Lua interpreter: Example tests
(run through the Lua interpreter directly) and unit tests (run through
busted). For unit tests, this should not make much of a difference and
example tests might later get similar treatment.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a C program which tests if the window manager handles
gravities correctly. This program is loosely based on metacity's
test-gravity.c, but completely rewritten and this version does automatic
tests instead of allowing the user to perform testing by hand.
By having this as a self-contained C program, it is possible to compare
awesome's behaviour with the behaviour of other WMs.
In my testing, only metacity and awesome pass this test. This is not
that much of a big surprise since awesome was fixed in
https://github.com/awesomeWM/awesome/pull/505 to work correctly with
metacity's test-gravity.c. However, I am surprised that e.g. Fluxbox
gets this wrong.
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>
The build files do not get updated on source changes currently anyway
(as a dependency of these targets), and this seems to be a leftover from
when `lua.in` files were used / pre-processing was required?!
The documentation for CMake's add_custom_command()-command says the
following for USES_TERMINAL:
The command will be given direct access to the terminal if possible.
With the ``Ninja`` generator, this places the command in the
``console`` ``pool``.
The result is that one can see the progress of tests/run.sh, because
messages appear immediately instead of delayed (instead all other
parallel steps are delayed; in practice this means luacheck output
appears only after tests/run.sh is done).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This also helps to easier spot failures because of this when looking
at the build matrix.
- Add new check-qa target, to be run only once.
- Add explicit check-unit-coverage target, used with DO_COVERAGE.
Instead of hardcoding the list of generated doc files as dependencies to
ldoc, we jump through some hoops to compute this dynamically.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A while ago, we made errors from ldoc fatal by default. Then a new ldoc
release appeared and caused problems for all of our users, because
awesome failed to work.
This patch reverts the previous fix so that we ignore ldoc warnings by
default again. However, to catch ldoc warnings on Travis, another
ldoc-building-target is added that fails on warnings. This new target is
included in our "check" target.
This fixes the intend of issue #1098 ("Users with ldoc version X cannot
build awesome"), but it does not actually employ the solution proposed
there ("Blacklist those ldoc versions"). Still, since this fixes the
intend of the issue, I count it as fixed.
Fixes: https://github.com/awesomeWM/awesome/issues/1098
Signed-off-by: Uli Schlachter <psychon@znc.in>
This meta-lua script takes the "raw" awesomerc.lua and turn it
into the final file and generate a documentation page from its
parsed content. It support
* Turn {{{ into markdown categories
* Turn top level comments into documentation
* Add custom documentation sections
* Parse the code to add links for each API calls
This helps generate a good entry point for new users wanting to
understand the content of rc.lua without searching the API by
hand.
Over time, this will also become the basis of the documentation.
If `rc.lua` is separated into several files, this will be easy to fix
this script. It could even do the separation itself from a monolitic
file using the already implemented {{{ parser.
Currently, tests/run.sh expects the directory layout that our wrapper Makefile
sets up before running CMake. This commit adds support for any other directory
configuration as well.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds a new "luacheck" target to the Makefiles. This target is
automatically included in "make check" when luacheck is found in $PATH.
Additionally, this includes luacheck in Travis so that the build fails when
luacheck complains about something.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of copying images to ${BUILD_DIR}/docs/images, which is the directory
with the input to ldoc, this now copies the images to ${BUILD_DIR}/doc/images,
which is where ldoc generates its output. That way, the images are together with
the html files and are automatically picked up by a lot of stuff.
Fixes: https://github.com/awesomeWM/awesome/issues/681
Signed-off-by: Uli Schlachter <psychon@znc.in>
Via this commit, any warnings from LDoc are fatal and make "make" fail. The
intention is to cause failures on Travis for PRs that introduce broken
documentation.
Closes: https://github.com/awesomeWM/awesome/issues/643
Signed-off-by: Uli Schlachter <psychon@znc.in>
- Remove `-rdynamic` from "CFLAGS" and count on CMake to pass it to
the compiler at the link phase (Issue #450).
- Move the definition of "CFLAGS" from `awesomeConfig.cmake` to
`CMakeLists.txt` and give it a name, `AWESOME_C_FLAGS`, so that the
relation between the target and the flags is made clearer and
manageable.
- Make `AWESOME_C_FLAGS` a cached variable so that the developers can
tweak the flags promptly in accordance with their necessities without
changing the prescribed value.
- Add a logic to cope with the case where CMake fails to set
`-rdynamic`.
Closes https://github.com/awesomeWM/awesome/pull/453.
With version 2.0rc5, Busted started cleaning up between tests more thoroughly.
The result was that it managed to unload and reload lgi. However, the C part of
lgi is not safe to be reloaded. This caused sporadic errors in the test suite
runs.
Work around this via a helper script that is run before Busted starts running
tests. When we load lgi in this helper script, it is loaded before Busted starts
saving and restoring everything and thus lgi won't ever be unloaded.
Signed-off-by: Uli Schlachter <psychon@znc.in>
