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>
Sorry if your libc doesn't have this, but it's not my problem.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: Ran Benita <ran234@gmail.com>
This reverts commit bf9fdceef6.
We really only want to expose symbols that we explicitly mark as part of
the API. This may not work with other platforms or compilers, but the
fact that private symbols are not available on Linux+GCC is enough of an
incentive to not use those.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
The default value ${dataroot}/X11/xkb only works if xkeyboard-config
has created the keymaps in that directory. Let's obtain the true final
value of where the keymaps are and use that as a default. In a production
environment this is the only value that can work.
This new default value also has the merit of making the 'check' target
to work in distcheck which does not have a copy of the xkeyboard-config
keymaps in its sandbox based on ${dataroot}/X11/xkb. The test data
cannot find the "include" keymaps it needs.
.../libxkbcommon-0.1.0/_inst/share/X11/xkb
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
This program is a utility to generated a header file.
The header file it generates should not be located in the
directory where this utility program is compiled.
Move the /makekeys dir as a sibling of /src.
This reduces the number of bi-directional relationships
between directories.
Make corresponding makefiles simplifications.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
These automake variables are not currently used.
The variable KS_HEADERS is not required anymore.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
CFLAGS is a user variable which should never be set by the configuration.
It allows the user to alter the configuration compiler options.
The visibility is only set for GNU compiler, leaving libraries built
with other compilers with the wrong visibility.
All other xorg libraries set visibilty using _X_EXPORT or _X_HIDDEN.
For the time being, all the symbols will have the default visibility
which does not break anything.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Rather than appending X11 to the include dir.
It should be safe to use as it has been added in 2005.
Use a local variable name matching the pkgconfig name.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
If pkg-config is missing, the configuration fails while initializing
XORG_* macros:
warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
line 11622: PKG_PROG_PKG_CONFIG: command not found
The output is sufficient to locate the problem.
It is not possible, or very difficult, to not have pkg-config
installed as the whole desktop and countless other software
depends on it.
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Autoconf does not handle this scenario as well as Automake does.
If xkbparse.c is already there, do not abort the configuration
if yacc is missing as it is not needed.
If both xkbparse.c and yacc are missing, abort configuration.
Yacc is a required tool to build the package.
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
XORG_STRICT_OPTION from XORG_DEFAULT_OPTIONS calls
AC_PROG_C_C99. This sets gcc with -std=gnu99.
If AC_PROG_CC macro is called afterwards, it resets CC to gcc.
Acked-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
This will handle AM_SILENT_RULES such that it will not break
on earlier Autoconf versions.
It provides a host of other configuration items
Acked-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
This is the current minimum version required for all X.Org modules.
The module can be configured with any higher version.
Autoconf features from version > 2.60 cannot be used.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
libtoolize: Consider adding "AC_CONFIG_MACRO_DIR([m4])" to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding "-I m4" to ACLOCAL_AMFLAGS in Makefile.am.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>