kc3-lang/libxkbcommon/test/data

test/data

Log

Author Commit Date CI Message
Peter Hutterer ca033a29 2019-09-03T11:23:14 rules: add include statements to rules files The majority use-case for extending XKB on a machine is to override one or a few keys with custom keycodes, not to define whole layouts. Previously, we relied on the rules file to be a single file, making it hard to extend. libxkbcommon parses $XDG_CONFIG_HOME/xkb/ but that only works as long as there is a rule that matches the user-specified RMLVO. This works for MLV but not for options which don't have a wildcard defined. Users have to copy the whole rules file and then work from there - not something easy to extend and maintain. This patch adds a new ! include directive to rules files that allows including another file. The file path must be without quotes and may not start with the literal "include". Two directives are supported, %H to $HOME and %S for the system-installed rules directory (usually /usr/share/X11/xkb/rules). A user would typically use a custom rules file like this: ! option = symbols custom:foo = +custom(foo) custom:bar = +custom(baz) ! include %S/evdev Where the above defines the two options and then includes the system-installed evdev rule. Since most current implementations default to loading the "evdev" ruleset, it's best to name this $XDG_CONFIG_HOME/xkb/rules/evdev, but any valid name is allowed. The include functionally replaces the line with the content of the included file which means the behavior of rules files is maintained. Specifically, custom options must be defined before including another file because the first match usually wins. In other words, the following ruleset will not assign my_model as one would expect: ! include %S/evdev ! model = symbols my_model = +custom(foo) The default evdev ruleset has wildcards for model and those match before the my_model is hit. The actual resolved components need only be in one of the XKB lookup directories, e.g. for the example above: $ cat $XDG_CONFIG_HOME/xkb/symbols/custom partial alphanumeric_keys xkb_symbols "foo" { key <TLDE> { [ VoidSymbol ] }; }; partial alphanumeric_keys xkb_symbols "baz" { key <AB01> { [ k, K ] }; }; This can then be loaded with the XKB option "custom:foo,custom:bar". The use of "custom" is just as an example, there are no naming requirements beyond avoiding already-used ones. Also note the bar/baz above - the option names don't have to match the component names. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ran Benita 076047b2 2019-10-16T10:32:19 keymap-dump: use consistent capitalization for "Group<N>" It's used capitalized everywhere except a couple places. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita a6ed0304 2019-10-16T10:27:12 keymap-dump: fix invalid names used for levels above 8 xkbcomp only accepts the "Level" prefix for a level name for levels 1 to 8, but the keymap dumping code added it always, e.g. "Level15". The plain integer, e.g. "8", "15" is always accepted, so just use that. Fixes https://github.com/xkbcommon/libxkbcommon/issues/113 Signed-off-by: Ran Benita <ran@unusedvar.com> Reported-by: progandy
Ran Benita 6456835f 2017-12-03T13:04:35 test/data: sync with xkeyboard-config 2.22 Some tweaks to the de(neo) keyseq tests were required. It seems to have improved. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 74f85d05 2015-08-23T23:02:10 test/x11comp: remove duplicate FOUR_LEVEL_KEYPAD from test keymap The `test/data/keymaps/host.xkb` file contains a duplicate definition of this type. On my computer (linux, xkbcomp 1.3.0, xserver 1.17.2), the test passes as is, but if I remove the duplicate definition, the roundtrip brings it back and the test fails. I can also reproduce it without relation to the test, by loading `test/data/keymaps/host.xkb` (without the duplicate) using xkbcomp -I $(pwd)/test/data/keymaps/host.xkb $DISPLAY and downloading it again using xkbcomp $DISPLAY out.xkb the duplicate is added. On Mac OS X however, the duplicate is removed (correctly), so the test fails there. xkbcommon itself, which was forked from xkbcomp, doesn't have this bug; in fact, doing ./test/print-compiled-keymap -k keymaps/host.xkb removes the duplicate if it is present. This is (probably) a regression in xkbcomp or xserver compared to the versions used in Mac OS X. Since getting a patch for any of these two is hopeless from my experience, I did not try to investigate further. I am not sure why, but if I also add a `PC_SUPER_LEVEL2` type, the duplicate of `FOUR_LEVEL_KEYPAD` doesn't show up. Hopefully the test will work on all platforms now. https://github.com/xkbcommon/libxkbcommon/issues/26 Reported-by: @nuko8 Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 312182ce 2014-10-16T17:55:46 test/data: add files for model=applealu_ansi layout=us Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c6ee6371 2014-10-16T17:48:00 test/data: sync to xkeyboard-config 2.13 (Run ./test/data/sync.sh). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 10a7a2bd 2013-10-27T20:37:27 test/compose: add new test Some results from the benchmark (compilation of en_US.UTF-8/Compose): $ grep 'model name' /proc/cpuinfo model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz $ uname -a Linux ran 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux $ ./test/compose bench compiled 1000 compose tables in 7.776488331s So according to the above benchmark and valgrind --tool=massif, an xkb_compose_table adds an overhead of about ~8ms time and ~130KB resident memory. For contrast, a plain US keymap adds an overhead of ~3ms time and 90KB resident memory. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 68962aa1 2014-09-21T23:54:34 keymap-dump: combine modifier_map's with the same modifier A bit less efficient, but makes for shorter, nicer output. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a931740c 2014-09-10T13:29:52 keycodes: fix keymap compilation with no aliases and malloc(0)==NULL If the keymap doesn't have any key-aliases (which is certainly possible), the calloc(num_key_aliases, ...) is allowed to return NULL according to the C standard, but this is not an error. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4df720b4 2014-08-09T22:14:34 test/x11-keyseq: new test It is like test/stringcomp, only instead of using xkb_keymap_new_from_string(), it uses xkbcomp to upload the keymap to a dummy Xvfb X server and then xkb_x11_keymap_new_from_device(). If any of these components are not present or fails, the test is shown as skipped. The test is messy, fragile, limited and depends on external tools, but I will improve on that later -- it's better to have a test. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 40f109af 2014-07-27T14:24:20 ast-build: make sure InterpDef is freeable With the following two rules: InterpretDecl : INTERPRET InterpretMatch OBRACE VarDeclList CBRACE SEMI { $2->def = $4; $$ = $2; } ; InterpretMatch : KeySym PLUS Expr { $$ = InterpCreate($1, $3); } | KeySym { $$ = InterpCreate($1, NULL); } ; And the fact that InterpCreate doesn't initialize ->def, if the VarDeclList fails, the %destructor tries to recursively free the uninitialized ->def VarDef. So always initialize it. That was the only problematic code in the parser for %destructor (I'm pretty sure). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita f5182bbd 2014-07-26T22:29:22 test: add file with a syntax error We didn't really have any. It also a exposes a memory leak, since the parser doesn't clean up the AST nodes of the discarded symbols. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 11a9f76b 2014-02-15T23:27:23 keymap-dump: don't print "affect=lock" in PtrLock It's the same as no flags, so might as well not print it. (In fact it is slightly harmful, because it actively *clears* the affect flags, which might have been set in some other manner. But in practice this cannot happen). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita ba7530fa 2013-11-27T13:43:57 scanner: restore lost DIVIDE token I don't know how this could have happened. Luckily this token is completely useless. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 65f9980b 2013-10-14T19:05:24 rules: fix scanning of line-continuation without leading space We were failing to scan something like\ this correctly. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9cef902d 2013-08-14T11:35:01 test: make sure keycode 0 works fine It is a legal keycode but we never tried it actually. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7caa1af2 2013-08-13T14:45:33 scanner: don't fail over unknown escape sequence This is too strict, and causes symbols/cz to fail parsing. Instead, just emit a warning (not shown by default): xkbcommon: WARNING: cz:75:19: unknown escape sequence in string literal https://bugs.freedesktop.org/show_bug.cgi?id=68056 Reported-By: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e91d2653 2013-08-01T23:09:46 scanner: allow empty key name literals Some keymaps actually have this, like the quartz.xkb which is tested. We need to support these. https://bugs.freedesktop.org/show_bug.cgi?id=67654 Reported-By: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e731b251 2013-08-01T20:24:27 xkbcomp: handle empty keymaps We should handle empty xkb_keycode and xkb_symbol sections, since xkbcomp handles them, and apparently XQuartz uses it. There are also files for it in xkeyboard-config (rules=base model=empty layout=empty, which translate to keycodes/empty and symbols/empty). https://bugs.freedesktop.org/show_bug.cgi?id=67654 Reported-By: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 0c8e9e0c 2013-07-22T18:43:53 test: sync test/data from xkeyboard-config 2.9 Needed for some tests. The tests need some adjustment, mostly because of the resolution of xkeyboard-config bug https://bugs.freedesktop.org/show_bug.cgi?id=50935 Also add the 'ch' symbols file for future tests. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 17a956d8 2013-05-09T14:47:09 Widen keycode range to 8/255 if possible (bug #63390) If the keycode range is smaller than 8 → 255, artifically widen it when dumping the keymap as not to displease X. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 4a59c84e 2013-02-25T12:09:17 keymap-dump: remove some ugly empty lines xkbcomp prints them too, but that's just annoying. Also xkb_keycodes doesn't have it already. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e95dac76 2013-02-25T12:03:06 keymap-dump: don't indent after xkb_keymap { xkbcomp doesn't indent there, so it's easier to diff. Also saves some horizontal space which is sorely needed when looking at these files (especially the xkb_symbols). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c7aef166 2013-02-19T15:57:14 keysym: print unicode keysyms uppercase and 0-padded Use the same format as XKeysymToString. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 089c3a18 2013-02-17T14:59:50 state: fix unbound virtual modifier bug Recent xkeyboard-config introduced the following line in symbols/level3: vmods = LevelThree, However, the XKM format which xkbcomp produces for the X server can't handle explicit virtual modifiers such as this: https://bugs.freedesktop.org/show_bug.cgi?id=4927 So by doing the following, for example: setxkbmap -layout de (or another 3-level layouts) xkbcomp $DISPLAY out.xkb xkbcomp out.xkb $DISPLAY The modifier is lost and can't be used for switching to Level3 (see the included test). We, however, are affected worse by this bug when we load the out.xkb keymap. First, the FOUR_LEVEL_ALPHABETIC key type has these entries: map[None] = Level1; map[Shift] = Level2; map[Lock] = Level2; map[LevelThree] = Level3; [...] Now, because the LevelThree virtual modifier is not bound to anything, the effective mask of the "map[LevelThree]" entry is just 0. So when the modifier state is empty (initial state), this entry is chosen, and we get Level3, instead of failing to match any entry and getting the default Level1. The difference in behavior from the xserver stems from this commit: acdad6058d52dc8a3e724dc95448300850d474f2 Which removed the entry->active field. Without bugs, this would be correct; however, it seems in this case we should just follow the server's behavior. The server sets the entry->active field like so in XKBMisc.c: /* entry is active if vmods are bound */ entry->active = (mask != 0); The xkblib spec explains this field, but does not specify how to initialize it. This commit does the same as above but more directly. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 40581106 2013-02-17T11:22:41 Sync test data from xkeyboard-config Sync the files again from xkeyboard-config 2.8, since there have been some changes we should test against. Also added a script test/data/sync.sh if we want to do it again in the future. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 22684cd1 2012-09-30T10:50:38 parser: remove XkbCompMapList rule This rule allows you to put several xkb_keymaps in one file. This doesn't make any sense: only the default/first can ever be used, yet the others are fully parsed as well. Different keymaps should just be put in different files. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 92e07726 2012-09-27T20:16:12 test: add keycodes files which map directly to evdev codes This is a proof-of-concept for the long key names. The keycodes in the file evdev-xkbcommon are autogenerated from linux/input.h, and uses the names given there; all of the previous names are aliased to the new names, so they continue to work with the symbols files, etc. You can try it with 'sudo ./test/interactive -r evdev-xkbcommon -n 0' The -n 0 means that we don't offset the evdev scan codes - just feed them directly. The -r evdev-xkbcommon just means to use a new rules file which makes us use the new keycodes file. (The only problem I can see is with the MENU and LSGT names which has some conflicts). Maybe some day xkeyboard-config could ship something similar, so that the 8 offset is unneeded. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 32c19f4b 2012-09-27T21:30:29 keymap-dump: make it look better with long key names Not worth messing around with too much, just make it legible. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4b69d6f7 2012-09-15T02:09:34 keycodes: ignore explicit minimum/maximum statements These statements are pretty pointless for us; we don't restrict keycodes like X does, and if someone writes e.g. maximum = 255 but only has 100 keys, we currently happily alloc all those empty keys. xkbcomp already handles the case when these statements aren't given, and uses a computed min/max instead. We should just always use that. (Of course since keycodes/evdev currently uses almost all of the keycodes in the range it declares, including 255, this doesn't save any memory for the common user right now). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a9fa3739 2012-09-12T16:39:54 keymap-dump: don't write spaces between multiple-syms-per-level This can get a bit unwieldy. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7f04ffc4 2012-08-29T12:10:28 rules: fix check for appending '|' character when applying There are two ways to separate multiple files in XKB include statements: '+' will cause the later file to override the first in case of conflict, while '|' will cause it augment it (this is done by xkbcomp). '!' is unrelated here. Since '|' is practically never used, this wasn't noticed. In the modified test, the '|some_compat' previously was just ignored. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 2a026f6f 2012-08-28T15:55:35 test/data/symbols: keypad can only have one default section Avoids a warning, from xkeyboard-config: commit 6676053f2c93596c2aaa9905151a5c76355a1540 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Fri Jun 29 09:53:45 2012 +1000 symbols: keypad can only have one default section Warning: Multiple default components in keypad Using x11, ignoring pointerkeys Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9de067aa 2012-08-27T21:31:18 compat: ignore "group" (compatibility) statements Group compatibility statements are like the following: group 3 = AltGr; This currently results in: keymap->groups[2].mask = <real mod mapped from AltGr vmod> And we don't do any thing with this value later. The reason it exists in XKB is to support non-XKB clients (i.e. XKB support disabled entirely in the server), which do not know the concept of "group", and use some modifier to distinguish between the first and second keyboard layouts (usually with the AltGr key). We don't care about all of that, so we can forget about it. One artifact of this removal is that xkb_map_num_groups no longer works, because it counted through keymap->groups (this wasn't entirely correct BTW). Instead we add a new num_groups member to the keymap, which just hold the maximum among the xkb_key's num_groups. This also means we don't have to compute anything just to get the number of groups. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 16f2de8b 2012-08-14T16:26:30 compat: ignore "locking" field in sym interprets This field is used in conjunction with key behaviors, which we don't support since c1ea23da5. This is also unused in xkeyboard-config. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7ef359de 2012-08-12T18:16:52 rulescomp: remove bad failtests Since we now handle empty model/layout, the last couple of tests should not fail. The reason they do is bacause they try to use a non-existent "base" rules file. When the file is brought in these tests do not fail. Since we already test for non-existent rules file, we can remove them, and refine the other tests a bit. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 93f6517c 2012-08-03T04:07:33 stringcomp: Make test more punishing Recreate the old test/dump scenario, where we test the following map: - rules: evdev - model: pc104 - layout #1: us - layout #2: ru - layout #3: ca(multix) - layout #4: de(neo) This is ever so slightly altered from the xkbcomp output; running the following: setxkbmap -rules evdev -model pc105 -layout us,ru,ca,de -variant ,,multix,neo -print | xkbcomp -xkb - - will give you a map with RCTL added to the modifier_map for both Control and Mod3. Running the output through xkbcomp -xkb - - again, will give you RCTL only added to Mod3. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone e756e9b5 2012-08-03T04:02:31 test/dump: Remove superfluous test No longer necessary now we have stringcomp doing a full round-trip test for us. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 39da9274 2012-08-03T03:38:46 stringcomp: Update input file for output changes Bring the input file into line with recent changes to the dump output, so we're as close as we can get to a round trip. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 6701fb5f 2012-08-03T03:54:44 stringcomp: Remove unnecessary Level1 mappings As a map will implicitly go to level one unless explicitly mentioned otherwise, remove all explicit =Level1 mappings, except for those with preserve entries. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita b0b11c4e 2012-08-02T00:29:07 types: don't use canonical/required types Xkb required every keymap to have at least the four following canonical types: ONE_LEVEL, TWO_LEVEL, ALPHABETIC, KEYPAD. This is specified in e.g. the kbproto spec and XkbKeyTypesForCoreSymbols(3) man page. If these types are not specified in the keymap, the code specifically checks for them and adds them to the 4 first places in the types array, such that they exist in every keymap. These are also the types (along with some non-required 4-level ones) that are automatically assigned to keys which do not explicitly declare a type (see FindAutomaticType in symbols.c, this commit doesn't touch these heuristics, whcih are also not very nice but necessary). The xkeyboard-config does not rely on the builtin xkbcomp definitions of these types and does specify them explicitly, in types/basic and types/numpad, which are virtually always included. This commit removes the special behavior: - The code is ugly and makes keytypes.c harder to read. - The code practically never gets run - everyone who uses xkeyboard-config or a keymap based upon it (i.e. everyone) doesn't need it. So it doesn't get tested. - It mixes policy with implementation for not very good reasons, it seems mostly for default compatibility with X11 core. - And of course we don't need to remain compatible with Xkb ABI neither. Instead, if we read a keymap with no types specified at all, we simply assign all keys a default one-level type (like ONE_LEVEL), and issue plenty of warnings to make it clear (with verbosity >= 3). Note that this default can actually be changed from within the keymap, by writing something like type.modifier = Shift type.whatever_field = value in the top level of the xkb_types section. (This functionality is completely unused as well today, BTW, but makes some sense). This change means that if someone writes a keymap from scratch and doesn't add say ALPHABETIC, then something like <AE11> = { [ q Q ]; }; will ignore the second level. But as stated above this should never happen. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a681c624 2012-08-07T08:17:26 types: remove DeleteLevel1MapEntries If there is no map entry for some modifier combination, the default is to use level 1. The removed code is an optimization to save some space by removing these entries. But it doesn't actually save any space, and did not in fact remove all level 1 entries (it walks the array while modifying it so there's an off-by-one error). We can instead keep them in the types but just not print them in keymap-dump.c, to get about the same behavior. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c6279b8b 2012-07-23T21:21:03 expr: don't divide by zero Calculator parser 101. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 3640e14d 2012-07-13T00:39:34 Add multiple-keysyms-per-level to test data Make sure this keeps on working. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone a77e9a92 2012-07-13T00:12:57 tests: Update dump.data for recent fixes Makes the test pass again. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita f0599675 2012-07-11T16:16:20 dump: add back kccgst names Readd the component names to the keymap->names struct. This is used when printing the component, e.g. xkb_keymap { xkb_keycodes "evdev+aliases(qwerty)" { instead of xkb_keymap { xkb_keycodes { This makes diffing against xkbcomp $DISPLAY a bit easier and is kind of useful anyway. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita fe5bfdf9 2012-07-11T16:35:43 dump: a few more tweaks to match xkbcomp output Only uppercase / lowercase stuff. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9e505225 2012-07-12T19:28:52 symbols: fix bug in modifier_map handling The code used to match a keysym to a keycode (see added comment) differed in behavior from xkbcomp, always taking the first key it found. This caused some incorrect interpretation of the xkeyboard-config data, for example the one corrected in dump.data (see the diff): since the de-neo layout sets the both_capslock option, the Left Shift key (LFSH) has the Caps_Lock keysym in group 4 level 2; now since keycode(Left Shift) = 50 < keycode(Caps Lock) = 64 the Left Shift one was picked, instead of the Caps Lock one which is group 1 level 1. The correct behavior is to pick according to group, level, keycode. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 62deaeb5 2012-07-12T14:42:31 Import dataset into test/data/ Use a self-contained dataset instead of relying on a globally-installed set. Data taken from xkeyboard-config 2.5.1. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 059c1842 2012-07-12T12:02:19 Move test data files to test/data/keymaps Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 19f814f9 2012-07-11T14:08:28 rules: fix parsing of multiple options This was broken by commit 18d331b86b4942ba54fe087ca07e47c9383d768b (where only the first option out of a comma-separated string was matched). Do it correctly this time and add a test. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita d0718e98 2012-06-05T17:48:08 test/dump: allow to run manually Without the srcdir envvar (and a couple trivial changes). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 869c6871 2012-05-19T02:35:15 rules: add test 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>
Ran Benita 4b49e0a1 2012-03-31T02:44:39 Overhaul test suite 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.]
kmx.io     mail     discord kmxgit v0.4.0