It does not seem to be required by tests (anymore), and fails when the
source dir is mounted read-only (which is the case for the Docker based
builds I am working on).
I think it is clearer anyway to run it as `build/awesome`.
If `cmake ..` in the build dir failed (e.g. because Lua could not be
found), a subsequent `make` will cause a strange error (this is in
non-quiet mode):
```
/src/awesome # make
echo "Running make Makefile…"
Running make Makefile…
make -C build Makefile
make[1]: Entering directory '/src/awesome/build'
make[1]: *** No rule to make target 'Makefile'. Stop.
make[1]: Leaving directory '/src/awesome/build'
make: *** [Makefile:44: Makefile] Error 2
```
With `s` in `MAKEFLAGS` (at the top of our Makefile):
```
Running make check-unit…
make[1]: *** No rule to make target 'check-unit'. Stop.
make: *** [Makefile:44: check-unit] Error 2
```
Therefore this patch looks for build/Makefile to be generated really.
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, running make in the build/ directory depended on the "cmake"
target which was running the cmake command. This target was phony,
meaning that it was always considered to be out of date and needed to be
re-generated.
Change this so that instead things depend on the CMakeCache.txt file. If
that file is already there, we do not re-run cmake.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This fixes among things:
* cmake has a clean target that doesn't redo cmake, use it, implement
distclean for what clean did.
* cmake is aware that it has to reconfigure, let id be clever about that
instead of being half clever ourselves.
* Don't have a *build* symlink and a *build* target, this is confusing.
* Forward things we don't know about to cmake.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
Add missing -f so that ln doesn't complain about target existing.
Be sure that the toplevel makefile is silent instead of custom @'s.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
We now have the beginnings of a flexible widget structure for the statusbar.
For now, there is no behavioural change, and the interface is a bit crude, but
watch this space!
Hi there.
awesome-client is now linked against the whole hog of x-related libs
that awesome depends on. These get pulled in by awesome-client using the
same LDFLAGS as awesome. Removing x-related libs from the LDFLAGS for
awesome-client is only half of the story, as it also depends on util.c
which now has a couple of x-related functions. The attached patch also
splits these functions into a separate xutil.{c,h} file pair and teaches
the rest of the files to use them. Apart from the small difference in
file size (I see a 3-3.5% decrease in file size, both for a stripped and
a non-stripped awesome-client binary), this should also somewhat reduce
the startup time (since awesome-client won't have to map all of these
libraries).
Cheers...
\n\n
Daniel Hahler
Uli Schlachter
Daniel Hahler
Julien Danjou
Pierre Habouzit
Hans Ulrich Niedermann
Aldo Cortesi
marco candrian
MATSUU Takuto
Nikos Ntarmos
daniel@brinkers.de