We probably don't want to get a privileged process to compile arbitrary
keymaps. So we should be careful about the envvars which control include
paths or default RMLVOs. But then secure_getenv is more sensible for
everything we do.
Signed-off-by: Ran Benita <ran234@gmail.com>
- Use 'test =' instead of 'test ==' in the x11 test. The second one
might not work with e.g. dash, whoops.
- Use AS_IF instead of 'if'. It actually blends in better..
Signed-off-by: Ran Benita <ran234@gmail.com>
These are function to create an xkb_keymap directly from XKB requests
to the X server. This opens up the possibility for X clients to use
xcb + xcb-xkb + xkbcommon as a proper replacement for Xlib + xkbfile for
keyboard support.
The X11 support must be enabled with --enable-x11 for now.
The functions are in xkbcommon/xkbcommon-x11.h. It depends on a recent
libxcb with xkb enabled. The functions are in a new libxkbcommon-x11.so,
with a new pkg-config file, etc. so that the packages may be split, and
libxkbcommon.so itself remains dependency-free.
Why not just use the RMLVO that the server puts in the _XKB_RULES_NAMES
property? This does not account for custom keymaps, on-the-fly keymap
modifications, remote clients, etc., so is not a proper solution in
practice. Also, some servers don't even set it. Now, the client just
needs to recreate the keymap in response to a change in the server's
keymap (as Xlib clients do with XRefreshKeyboardMapping() and friends).
Signed-off-by: Ran Benita <ran234@gmail.com>
This helps ensure we don't ship a library with undefined symbols, which
can easily happen with multiple inter-dependent DSOs.
Signed-off-by: Ran Benita <ran234@gmail.com>
Add a NEWS file, with some retroactive entries. Also add 'check-news' to
configure.ac, though this might be a bit annoying.
Signed-off-by: Ran Benita <ran234@gmail.com>
Older Automakes give this error without this directive:
Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in `configure.ac'
In newer autotools this is included under AC_PROG_CC, but it's harmless
to add.
https://github.com/xkbcommon/libxkbcommon/issues/3
Signed-off-by: Ran Benita <ran234@gmail.com>
We now also work with byacc (version tested: 20130925) which some people
prefer, perhaps due to its license (public domain) or performance
(haven't compared).
When using byacc, currently the following warning comes up:
src/xkbcomp/parser.c:954:14: warning: declaration shadows a variable in the global scope [-Wshadow]
YYSTYPE yylval;
^
src/xkbcomp/parser.c:37:20: note: expanded from macro 'yylval'
#define yylval _xkbcommon_lval
^
./src/xkbcomp/parser.h:96:16: note: previous declaration is here
extern YYSTYPE _xkbcommon_lval;
This is due to a bug in byacc - it shouldn't output that extern line in
%pure-parser mode. So the warning stays.
Signed-off-by: Ran Benita <ran234@gmail.com>
The scanner is very similar in structure to the one in xkbcomp/rules.c.
It avoids copying and has nicer error reporting.
It uses gperf to generate a hashtable for the keywords, which gives a
nice speed boost (compared to the naive strcasecmp method at least). But
since there's hardly a reason to regenerate it every time and require
people to install gperf, the output (keywords.c) is added here as well.
Here are some stats from test/rulescomp:
Before:
compiled 1000 keymaps in 4.052939625s
==22063== total heap usage: 101,101 allocs, 101,101 frees, 11,840,834 bytes allocated
After:
compiled 1000 keymaps in 3.519665434s
==26505== total heap usage: 99,945 allocs, 99,945 frees, 7,033,608 bytes allocated
Signed-off-by: Ran Benita <ran234@gmail.com>
This wraps the current mmap call and adds a fallback implementation for
systems which do not have mmap (e.g. mingw).
Signed-off-by: Ran Benita <ran234@gmail.com>
You can now set default values in the environment, as well as a context
option to ignore the environment, e.g. for tests.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some tests use linux/input.h (and epoll), but we're building on some
other kernels (e.g. debian freebsd). We could just copy the file but
it's GPL. We could also skip the tests (exit code 77) but it doesn't
really matter.
Signed-off-by: Ran Benita <ran234@gmail.com>
Why not.
Also forgot to update the xorg-utils error message when bumping the
requirement.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Changed to xkbcommon.org.]
We definitely don't need .gz anymore, and .bz2 seems on its way out.
Mirror what Wayland does, and move to .xz exclusively.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The configure test shouldn't touch CFLAGS, because they come last on the
command line and allow to users to override settings if needed.
Signed-off-by: Ran Benita <ran234@gmail.com>
We still use pkg-config to get the xkb_base variable from
xkeyboard-config, but we removed all of the other PKG_ macro calls. This
still works now, because XORG_DEFAULT_OPTIONS runs it somehow. But we
shouldn't rely on it.
Signed-off-by: Ran Benita <ran234@gmail.com>
The ks_tables.h file is generated by makekeys.py from
xkbcommon-keysyms.h, which in turn is generated initially by 'make
update-keysyms'. The xkbcommon-keysyms.h file is commited to git and
distributed in the tarball. Since ks_tables.h should only ever change
when xkbcommon-keysyms.h changes, it is more sensible to update them
together and treat them the same, instead of generating ks_tables.h
every time for every builder with 'make', as we do now.
This means we don't need python as a build dependency (only the one
running update-keysyms, i.e. no one, needs this), and we can be
sure exactly the same file is used by everyone. We also don't need to
run makekeys.py on every build.
Signed-off-by: Ran Benita <ran234@gmail.com>
This removes the complicated and undocumented hash-table creation-helper
and replaces it with an autogenerated sorted array. The search uses simple
bsearch() now.
We also tried using gperf but it turned out to generate way to big
hashtables and when reducing the size it isn't really faster than
bsearch() anymore.
There are no users complaining about the speed of keysym lookups and we
have no benchmarks that tell that we are horribly slow. Hence, we can
safely use the simpler approach and drop all that old code.
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Simple HTML docs generated from the doxygen comments.
After running 'make' or 'make doc', try firefox doc/html/index.html to
see it (if you have doxygen). It's also installed with 'make install'.
You can use --enable-docs or --disable-docs, or specifically
--with-doxygen or --without-doxygen (autodetected, default yes).
The docs are currently not distributed in the tarball, because I
couldn't make it work properly in all cases :/
Signed-off-by: Ran Benita <ran234@gmail.com>
Right now it just comes from build-time, but eventually this should be
sourced from configuration files at runtime too.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Since every user building the library, even from git, doesn't need these
files anymore, there's no need to check for them (this goes for makekeys
as well).
The only remaining user is the update-keysyms target, but whoever will
run it again (if ever) will probably know what he's doing (at least
enough to run git diff before git commit). And the defaults should be
fine too.
Signed-off-by: Ran Benita <ran234@gmail.com>
Add a non-extensive test to check that some basic things (e.g. rule
matching, var substitution, indexes and groups) work as expected.
Signed-off-by: Ran Benita <ran234@gmail.com>
makekeys must be built with the build-native compiler, not with $(CC)
which is the cross-compiler. The only sane way to achieve this seems to
be to use a separate Makefile.am for it.
This patch fixes the problem apparently caused by:
commit b5efe41f19
Author: Ran Benita <ran234@gmail.com>
Date: Sat Mar 24 04:48:31 2012 +0200
Make build non-recursive
There is no such thing as makekeys_makekeys_CC in automake.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Rewrite all of the current tests in the following ways:
- Instead of the current mix of C and shell, just use single-process
pure C file per test. All of the .sh files are removed, but everything
that was tested is ported.
- Instead of handling the test logs ourselves, use Automake's
"parallel-test" mechanism. This will create a single log file for each
test with it's stdout+stderr, and a top level "test-suite.log" file
for all the failed tests.
- The "parallel-tests" directive also makes the test run in parallel,
so "make check" runs faster.
- Also use the "color-tests" directive to have the "make check" output
colorized. Who doesn't like to see PASS in green?
- All of the test data files are moved into the test/data subdirectory.
That way we can just put the directory in EXTRA_DIST and forget about
it.
- The test/Makefile.am file is consolidated into the main Makefile.am,
for a completely non-recursive build.
Right now the tests are completely independent and just use simple
assert()'s. More sophistication can be added as needed.
It should also be noted that it's still possible to use shell, python,
etc. if a test wants more flexibility than C can provide, just do as
before.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_keymap changes.]
autotools was warning that AC_USE_SYSTEM_EXTENSIONS was being called too
late, so move it earlier. Also shove BASE_CFLAGS into CFLAGS so we get
all the added warning flags from xorg.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Unify all the different Makefile.am into a single short top level one
(the test/Makefile.am file is left intact though).
This makes the build system simpler to look and should encourage
unifying more currently-disparate code.
Some further motivation can be found in this page:
http://www.flameeyes.eu/autotools-mythbuster/automake/nonrecursive.html
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Daniel Stone
Damien Lespiau
Pekka Paalanen