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>
These scripts generate source code that is committed to git and hence do
not really belong in the build system. A maintainer runs them as needed.
Signed-off-by: Ran Benita <ran234@gmail.com>