kc3-lang/libxkbcommon/test/data
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
faac4ba7 | 2019-12-28 15:52:20 | test/data: ensure files are checked out with LF, not CRLF The tests stringcomp and buffercomp do binary comparison on some files; if the files are changed to CRLF on checkout, the tests fail. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
 |
ca033a29 | 2019-09-03 11: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> | |
|
076047b2 | 2019-10-16 10: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> | |
|
a6ed0304 | 2019-10-16 10: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 | |
 |
6456835f | 2017-12-03 13: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> | |
|
74f85d05 | 2015-08-23 23: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> | |
|
312182ce | 2014-10-16 17:55:46 | test/data: add files for model=applealu_ansi layout=us Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
c6ee6371 | 2014-10-16 17:48:00 | test/data: sync to xkeyboard-config 2.13 (Run ./test/data/sync.sh). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
10a7a2bd | 2013-10-27 20: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> | |
|
68962aa1 | 2014-09-21 23: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> | |
|
a931740c | 2014-09-10 13: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> | |
|
4df720b4 | 2014-08-09 22: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> | |
|
40f109af | 2014-07-27 14: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> | |
|
f5182bbd | 2014-07-26 22: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> | |
|
11a9f76b | 2014-02-15 23: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> | |
|
ba7530fa | 2013-11-27 13: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> | |
|
65f9980b | 2013-10-14 19: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> | |
|
9cef902d | 2013-08-14 11: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> | |
|
7caa1af2 | 2013-08-13 14: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> | |
|
e91d2653 | 2013-08-01 23: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> | |
|
e731b251 | 2013-08-01 20: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> | |
|
0c8e9e0c | 2013-07-22 18: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> | |
 |
17a956d8 | 2013-05-09 14: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> | |
|
4a59c84e | 2013-02-25 12: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> | |
|
e95dac76 | 2013-02-25 12: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> | |
|
c7aef166 | 2013-02-19 15:57:14 | keysym: print unicode keysyms uppercase and 0-padded Use the same format as XKeysymToString. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
089c3a18 | 2013-02-17 14: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> | |
|
40581106 | 2013-02-17 11: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> | |
|
22684cd1 | 2012-09-30 10: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> | |
|
92e07726 | 2012-09-27 20: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> | |
|
32c19f4b | 2012-09-27 21: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> | |
|
4b69d6f7 | 2012-09-15 02: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> | |
|
a9fa3739 | 2012-09-12 16: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> | |
|
7f04ffc4 | 2012-08-29 12: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> | |
|
2a026f6f | 2012-08-28 15: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> | |
|
9de067aa | 2012-08-27 21: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> | |
|
16f2de8b | 2012-08-14 16: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> | |
|
7ef359de | 2012-08-12 18: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> | |
|
93f6517c | 2012-08-03 04: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> | |
|
e756e9b5 | 2012-08-03 04: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> | |
|
6701fb5f | 2012-08-03 03: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> | |
|
39da9274 | 2012-08-03 03: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> | |
|
a681c624 | 2012-08-07 08: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> | |
|
b0b11c4e | 2012-08-02 00: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> | |
|
c6279b8b | 2012-07-23 21:21:03 | expr: don't divide by zero Calculator parser 101. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3640e14d | 2012-07-13 00:39:34 | Add multiple-keysyms-per-level to test data Make sure this keeps on working. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
a77e9a92 | 2012-07-13 00:12:57 | tests: Update dump.data for recent fixes Makes the test pass again. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
f0599675 | 2012-07-11 16: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> | |
|
fe5bfdf9 | 2012-07-11 16:35:43 | dump: a few more tweaks to match xkbcomp output Only uppercase / lowercase stuff. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9e505225 | 2012-07-12 19: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> | |
|
62deaeb5 | 2012-07-12 14: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> | |
|
059c1842 | 2012-07-12 12:02:19 | Move test data files to test/data/keymaps Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
19f814f9 | 2012-07-11 14: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> | |
|
d0718e98 | 2012-06-05 17: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> | |
|
869c6871 | 2012-05-19 02: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> | |
|
4b49e0a1 | 2012-03-31 02: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.] |