Trim the API a bit.
Also, just always use gettimeofday(), which is portable. Hopefully the
system clock doesn't change while a benchmark is running.
Signed-off-by: Ran Benita <ran234@gmail.com>
The CI image only has Python 3.4. It's a bit of a hassle to change this,
so let's pin meson to the version before they bumped their requirement
instead.
I suppose it's not that bad in that it will guarantee compatibility with
older meson over time.
Signed-off-by: Ran Benita <ran234@gmail.com>
Will be deprecated in automake 2.0.
Replaced by AC_CONFIG_MACRO_DIR (already present) which is available
since autoconf 2.63.
Signed-off-by: Ran Benita <ran234@gmail.com>
The x11 tests/demos did not depend on xcb and xcb-xkb directly, only
indirectly through link_with: libxkbcommon_x11_internal. So linking
worked, but the xcb and xcb-xkb cflags were *not* included when
compiling them. So when using xcb installed in a non-standard location,
what would happen is:
- Library will link with custom xcb and compile with custom xcb headers.
- Test will link with custom xcb and compile with system xcb headers (if
exist, otherwise fail).
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/57
Reported-by: @remexre
Signed-off-by: Ran Benita <ran234@gmail.com>
We will never remove the deprecated functions and there is no real
reason to annoy users into stop using them.
If there *will* be a reason, *then* we will add the attribute.
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/56
Signed-off-by: Ran Benita <ran234@gmail.com>
The default fallback type uses
type->level_names = NULL
but the keymap-dump code was not checking this case.
Instead of adding more workarounds and possible bugs (e.g. previous
commit), let's just keep the number of level names separately. This has
the additional advantage retains extraneous level name if someone adds
them for some reason.
Signed-off-by: Ran Benita <ran234@gmail.com>
The buggy code assigned the number of levels based on the number of
level names in the definition, instead of the actual number of levels!
This would completely break type definitions which do not give names to
levels.
This was not noticed for so long because xkeyboard-config always gives
names to all levels.
This regressed in 61fed8dab9.
Reported-by: Gatis Paeglis <gatis.paeglis@qt.io>
Signed-off-by: Ran Benita <ran234@gmail.com>
These can be useful in some odd cases.
There is already an implementation (+ tests) for internal use, so all
that's needed is to export them.
If xkbcommon were to provide a way to convert a Unicode codepoint to a
keysym, this could have been implemented externally as follows:
uint32_t codepoint = xkb_keysym_to_utf32(keysym);
uint32_t upper_codepoint = my_unicode_library_to_upper(codepoint);
xkb_keysym_t upper_keysym = theoretical_xkb_keysym_from_utf32(upper_codepoint);
However keysym -> codepoint is not injective so such a function is not
possible strictly speaking.
Signed-off-by: Ran Benita <ran234@gmail.com>
The previous code would cause failures to find the Compose file if one
of the environment variables LC_ALL, LC_CTYPE or LANG are set to the
empty string.
The description of the fallback procedure in loclale(7) talks about
"non-null environment variable"; I interpreted this to mean the
environment variable is unset, but it actually means unset or empty (I
verified this by looking at what glibc and musl do).
A recent bug in systemd https://github.com/systemd/systemd/issues/6407
exposed this issue. It causes these these variables to be set to the
empty string in TTY sessions.
Reported by "doodoo" in https://bbs.archlinux.org/viewtopic.php?id=228658
Signed-off-by: Ran Benita <ran234@gmail.com>
To be consistent with the meson build; also makes more sense as doxygen
can generate more than html (though we currently are not doing that).
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
The change in d44ba48 removed -I$(top_builddir)/src/xkbcomp, but this is
needed in order to find the generated parser.h file which is put in the
build dir.
I also added -I$(top_builddir)/src in order to match the meson behavior.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/50
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>
A bit more manageable this way, and the other part of the target is
already using python.
The output is the same, except I removed the reference to Makefile.am.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Matt Whitlock