Without the change build fails as:
ld: CMakeFiles/awesome.dir/objects/window.c.o:/build/source/build/common/lualib.h:31:
multiple definition of `lualib_dofunction_on_error';
CMakeFiles/awesome.dir/awesome.c.o:/build/source/build/common/lualib.h:31: first defined here
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
Add optional gtk3 support to Awesome so that the `beautiful.gtk` module can be
used.
The `beautiful.gtk` uses `lgi` to obtain Gtk via gobject-introspect:
return require('lgi').Gtk
Since the current build does not include the typelib files needed, the above
call fails.
It turns out that both `gtk3` and `atk` (Accessibility toolkit) are needed, so
this commit adds them as optional build inputs.
Setting `gtk3Support` to `true` e.g. in an overlay will make `beautiful.gtk`
work at the cost of an increased closure size (currently 99.6M vs 223.4M).
Fixes https://github.com/NixOS/nixpkgs/issues/60538
Using wrapProgram makes so that the generated "awesome" wrapper duplicates its
command line options at every restart.
As @psychon puts it:
> AwesomeWM restarts via execvp(argv[0], argv). In NixOS, wrapProgram is used
> to generate a wrapper around the real binary. wrapProgram calls makeWrapper
> with --argv0 '$0'. I guess this is what makes awesomeWM run the wrapper again
> on restart. Without this --argv0 awesomeWM would directly restart itself
> instead of the wrapper, I think.
This commit partly reinstates changes from 5465d6f that had been somehow
reverted in 17d3eb2. Also, a comment has been added in the hope that future
changes won't do the same.
Additionally, refactor the LUA_PATH env var to ensure that the internal lgi lua
files can't be required explicitly and to avoid possible name clashes (this
fixes issue #60232).
Finally, rather than using prepending `?.lua` append `;;` to LUA_PATH. Quoting
@psychon:
> This is interpreted by Lua as "add the default search path here" (which does
> indeed contain ?.lua, but also contains more).
Testing done:
- Build with `nix-build -I /path/to/repo -A awesome`
- Start an X session with xterm only
- Start xephyr, e.g. `Xephyr :1 -name xephyr -screen 512x384 -ac -br -noreset &`
- Run awesome like `DISPLAY=:1.0 ./result/bin/awesome`. Additionally, add
`--search` options to expose lua modules that have a name clash with lgi's
internal ones (see #60232 for more details) and `require` them in `rc.lua` to
prove that they are loaded correctly
I have no idea why gobjectIntrospection even was in here. The only
library in there, libgirepository-1.0.so, is not used by awesome. It is
only used by lgi.so and that means it should be found via its RPATH.
The Pango path is not needed in $LD_LIBRARY_PATH ever since
gobjectIntrospection started patching .typelib files with absolute
paths. Relevant commits are 36bef2b267 from 2014
("gobject-introspection: refer to shlibs with absolute paths in
typelibs") and c420de6b05 from 2016 ("gobject-introspection: Fix
patching shared objects").
The above patches did not work for cairo, because cairo's typelib is a
bit "special". However, this was fixed by e44038bcca some days ago
("gobjectIntrospection: use absolute path for cairo GIR").
Thus, setting $GI_TYPELIB_PATH is enough so that all needed libraries
are found.
Fixes: https://github.com/NixOS/nixpkgs/issues/14164
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of polluting the environment with environment variables which
are inherited by processes spawned from awesome, use the command line
argument "--search" to add things to the search path.
cc #33169
By default, awesome will use "devel" as a version name
(or `git describe`). This has led to awesome always
showing "devel" for its version.
Some extensions depend on version information to figure
out what features they can use.
This change overrides the version for the build from the
derivations' `version` attribute.
Awesome can load SVG images, just like it can do PNG, through gdk.
The support for SVG images through GDK needs librvsg.
This commits adds the plumbing necessary in the wrapper that makes
awesome be able to load SVG images.
Without this, awesome will not load SVG images. The related error message is:
> Couldn't recognize the image file format for file
Which comes from gdk.
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
Many (less easily automatically converted) old-style strings
remain.
Where there was any possible ambiguity about the exact version or
variant intended, nothing was changed. IANAL, nor a search robot.
Use `with stdenv.lib` wherever it makes sense.
- Move lgi to luaPackages
- Use luaPackages in awesome and passthru lua
- Allow to pass lua modules to the awesome WM so that those can be used in the configuration
