Kconfiglib.git/kconfiglib.py, branch v1.0.2

Use os.access() in get_defconfig_filename()

2017-09-24T12:11:56Z

...instead of os.path.exists(). This more closely mimics the test in the C implementation, which boils down to fopen(file, "r") == NULL. Could open(filename) and catch exceptions too, but it might be overkilling things.

Fix defconfig srctree absolute/relative mixup bug

2017-09-24T12:03:41Z

This code in zconf.l says !=, not ==. Thought the behavior seemed weird. if (!f && name != NULL && name[0] != '/') { env = getenv(SRCTREE); if (env) { sprintf(fullname, "%s/%s", env, name); f = fopen(fullname, "r"); } } return f; Thankfully only broken for a short while. Also gives much simpler code.

Handle path cleanups in a cleaner way

2017-09-24T11:14:25Z

_clean_up_path() was only ever passed filenames, so stripping trailing slashes was redundant. Better to strike at the root of the problem too, which is the os.path.join() with 'base_dir' defaulting to ".". The old hack gave incorrect results in obscure cases: Turning .//oops into /oops is wrong. The new version should be Windows-friendly as well.

Remove defaulted open() "r" argument

2017-09-24T11:13:48Z

Fix get_defconfig_filename() $srctree search order

2017-09-24T09:37:42Z

Previously, $srctree/path/to/defconfig would be looked up before /path/to/defconfig, and the code wouldn't check if /path/to/defconfig was an absolute path ($srctree is ignored otherwise). Sloppy old oversights. The behavior now fully matches the C implementation. Also fix some related things: - An 'if m' suffices to select a defconfig. We previously required 'y'. - Make the code less hacky and possibly more Windows-friendly by using os.path.relpath() to de-absolutize paths, and stop using os.path.normpath() as it could change the meaning of paths that contain symbolic links. - Explain what happens if 'option defconfig_list' is set on multiple symbols and print a warning in that case. - Fix get_srctree(). It would previously return "." instead of None if $srctree was unset at parse time. Somehow forgot to to test this. The code is now much more straightforward.

Add _parse_cond() helper for some 'if ' cases

2017-09-24T06:05:31Z

There's already parse_val_and_cond(), which handles ' if ' where both and need to be parsed. Add a corresponding _parse_cond() helper which can be used in cases where only should be parsed (for 'select', 'imply', and 'range'). Also move both _parse_val_and_cond() and _parse_cond() outside _parse_properties(). More explicit, and shows a small performance improvement during parsing.

Explain why _make_and() can return None

2017-09-22T05:58:06Z

Makes ANDs between nonexistent expressions yield a nonexistent expression.

Explain the expression structure clearer

2017-09-22T05:11:56Z

Simplify _expr_to_str()

2017-09-22T05:02:05Z

- Get rid of _sym_str_string(), which was only used here. - Remove 'if expr is None' case that could never trigger - Add a test for printing string symbols, as they are a bit tricky: Default values should not be evaluated to tristate values.

Simplify expression representation

2017-09-21T18:21:00Z

Store simple (, , ) tuples instead of (, [list of operands]) tuples. The thought process behind the original representation was to avoid creating lots of nodes for long X && Y && Z && ... chains that sometimes appear, and possibly speed up evaluation. In retrospect, it's pretty bad, for the following reasons: 1) _make_and() and _make_or() created lots of new merged lists instead of simply reusing the tuples already allocated for the subexpressions. This is slow and memory hungry. 2) Any gain in evaluating long expressions would barely offset slower evaluation of short expressions. 3) The code became more complex. Most importantly, this change makes expressions more straightforward to work with for people peeking into internals.