This makes the CMake run much faster in general, and does not re-check
the dependencies every time again (since it gets cached).
There are several reports where the reference to the missing module was
not provided, and they all appear to have happened with CMake 3.6.1.
A missing "foobar" module gets reported there, but if you remove
/usr/lib/pkgconfig/libstartup-notification-1.0.pc, this does not get
reported:
-- Checking for modules '…'
--
CMake Error at /tmp/cmake/share/cmake-3.6/Modules/FindPkgConfig.cmake:424 (message):
A required package was not found
This apparently affects modules that have version requirements. After
removing that from "libstartup-notification-1.0>=0.10", it gets reported
also: "No package 'libstartup-notification-1.0' found".
The workaround is to require the package without version information
before the requirement with the version information.
This reverts https://github.com/awesomeWM/awesome/pull/1253.
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>
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>
We were only using this for tag names. This means we are assuming that
everything is UTF8, but tag names are provided in the local locale and
need to be translated into UTF8? That makes no sense, so just drop this.
Fixes: https://github.com/awesomeWM/awesome/issues/1753
Signed-off-by: Uli Schlachter <psychon@znc.in>
This removes some @EXPANSIONS@ from Lua files and removes a hack that
was needed. All is better now! :-)
Signed-off-by: Uli Schlachter <psychon@znc.in>
- Execute the tests without compiling, and don't mess with the source
files when coverage is enabled.
This ensures that the coverage report lines are correct.
This disables the doc tests, as their results would be unused.
Hack: it still expands macros on util.lua, because of
`util.get_themes_dir()` and `util.get_awesome_icon_dir()`, which might
be moved later. Ref:
https://github.com/awesomeWM/awesome/pull/1239#discussion_r93828178.
- ensure that BUILD_APIDOC and DO_COVERAGE are not used together
- awesomeConfig.cmake: add DO_COVERAGE as an option
- Travis: only install codecov with DO_COVERAGE=codecov
- Travis: do not use set -v; use set -x with DO_COVERAGE
- do not use trailing slashes with dirs in tests/examples/CMakeLists.txt / .luacov
- Use latest luacov (0.12.0-1) again
This reverts parts of 4cc6a815.
I think it is better to fix any failure that 4cc6a815 tried to work around.
- Travis: simplify/fix require('luacov') for functionaltests
- tests/examples/CMakeLists.txt: resolve ../.. in SOURCE_DIR
- tests/examples/CMakeLists.txt: add DO_COVERAGE to env
- Cleanup/simplify .luacov: work with SOURCE_DIRECTORY alone
- tests/run.sh: pass through / set SOURCE_DIRECTORY when running awesome
- tests/run.sh: resolve source_dir
- use DO_COVERAGE from env only
It was currently done all at once. Therefore, the error message was:
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:415 (message):
A required package was not found
With no further information besides the full dependency list.
With this change, it will print the missing package.
Closes https://github.com/awesomeWM/awesome/pull/1253.
Instead of using Xlib for parsing resource files, this now uses the
dedicated xcb-based library that is meant for exactly this task.
Fixes: https://github.com/awesomeWM/awesome/issues/1176
Signed-off-by: Uli Schlachter <psychon@znc.in>
I don't know why we force CMAKE_BUILD_TYPE to be RELEASE, but I don't think we
should do that.
This also changes the default build type to something which does not contain
-DNDEBUG in CFLAGS. This means that assert()s will start to work.
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.
This system allow containers, widgets and layouts to be listed in
the documentation with an example screenshot.
It uses raw HTML due to ldoc limitations, but as it is autogenerated,
it wont be user visible.
As the documentation generation insert increasingly large ammount
of code into the lua files, the coverage data is getting less and
less accurate. This try to fix this by only collecting such data
after the `configure_file` calls are done.
Most of this information isn't interesting. If you are getting awesome from a
distro, then the time, hostname and username of the build are likely 'random
stuff' and if you are building awesome yourself, then the hostname and username
are obviously yours and the time can still be interfered based on the awesome's
binary ctime.
The GCC version shouldn't make any difference at all.
Closes https://github.com/awesomeWM/awesome/pull/566.
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.
Add a path to awesomeConfig.cmake for searching an iconv library and the
corresponding header file automatically if the build system is on Mac OS
X which needs to pass the header and library paths explicitly to the
compiler to build Awesome successfully.
Closes https://github.com/awesomeWM/awesome/pull/440.
This fixes "make (cmake)" picking up the files from the build dir itself
(recursively), i.e. "make cmake" would also create
`.build-HOST-x86_64-linux-gnu-4.9.2/.build-HOST-x86_64-linux-gnu-4.9.2/`.
It could also use `${AWE_SRCS}` etc here probably.
Daniel Hahler
Emmanuel Lepage Vallée
Daniel Hahler
Uli Schlachter
Uli Schlachter
Tomoya Tabuchi
Kazunobu Kuriyama
Kazunobu Kuriyama
actionless
Julian Wollrath
Heiko Becker
Peter Junos