This is the base tool, no subtools are currently connected so you only get help
and version for now. The goal here is to have a git-like infrastructure where
/usr/bin/xkbcli is the main tool, anything else will hide in libexec.
The infrastructure for this is copied from libinput. Tools themselves will
will be installed in $prefix/libexec/xkbcommon and the xkbcli tool forks
off whatever argv[1] is after modifying the PATH to include the libexec dir.
libinput has additional code for checking whether we're running this from the
builddir but it's a bit iffy and it's usefulness is limited - if you're in the
builddir anyway you can just run ./builddir/xkbcli-<toolname> directly.
So for this code here, running ./builddir/xkbcli <toolname> will execute the
one in the prefix/libexecdir.
Since we want that tool available everywhere even where some of the subtools
aren't present, we need to ifdef the getopt handling.
man page generation is handled via ronn which is a ruby program but allows
markdown for the sources. It's hidden behind a meson option to disable where
downloading ronn isn't an option. The setup is generic enough that we can add
other man-pages by just appending to the array.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This library is the replacement for clients parsing evdev.xml directly.
Instead, they should use the API here so that in the future we may even
be able to swap evdev.xml for a more suitable data format.
The library parses through evdev.xml (using libxml2) and - if requested -
through evdev.extras.xml as well. The merge approach is optimised for
the default case where we have a system-installed rules XML and another file in
$XDG_CONFIG_DIR that adds a few entries. We load the system file first, then
append any custom ones to that. It's not possible to overwrite the MLVO list
provided by the system files - if you want to do that, get the change upstream.
XML validation is handled through the DTD itself which means we only need to
check for a nonempty name, everything else the DTD validation should complain
about.
The logging system is effectively identical to xkbcommon.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Meson is easier to maintain, much faster, encourages better practices,
and is not built on a pile of shell scripts.
The autotools build system is kept intact for now, in order to ease the
migration. The intention is to remove it sooner rather than later, if
all goes well.
Run `meson build && mesonconf build` to see the configuration options
for the new system. Conversion should be straightforward. Environment
variables like CFLAGS work the same.
If meson is used, xorg-util-macros is not required.
In terms of functionality the two systems have about the same
capabilities. Here are some differences I noticed:
- Meson uses `-g` by default, autotools uses `-g -O2`.
- In autotools the default behavior is to install both static and shared
versions of the libraries. In meson the user must choose exactly one
(using -Ddefault_library=static/shared).
It is possible to workaround if needed (install twice...), but
hopefully meson will add the option in the future.
- Autotools has builtin ctags/cscope targets, meson doesn't.
Easy to run the tools directly.
- Meson has builtin benchmarks target. Handy.
- Meson has builtin support for sanitizers/clang-analyzer/lto/pgo/
coverage etc. Also handy.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Peter Hutterer
Ran Benita