Fork of https://github.com/zephyrproject-rtos/Kconfiglib.git https://git.mcdonnell.dev/Kconfiglib.git/atom?h=v3.1.0 2018-02-16T09:10:34Z 2018-02-16T09:10:34Z Ulf Magnusson ulfalizer@gmail.com 2018-02-16T09:05:16Z urn:sha1:2a88c0cc5707eb0761d87cfd2ca171ce687258fc Direct dependencies are significant for 'imply' even if the symbol has no properties, so they need to be included to get semantically equivalent output. Making the direct dependencies clear is helpful in general too, even if you can usually infer them from the properties they get propagated to. 2018-02-08T23:50:03Z Ulf Magnusson ulfalizer@gmail.com 2018-02-08T23:31:50Z urn:sha1:0d44b9e2f47a5a993ab44a1c5355c2ae245d4525 The visibility of a symbol in an y-mode choice can only be n or y, so it's sufficient to check that it's not n (0). 2018-02-08T12:07:41Z Ulf Magnusson ulfalizer@gmail.com 2018-02-08T12:07:41Z urn:sha1:6f3163095edb7663a1186963c3b2dcb520e06a64 2018-02-08T11:38:03Z Ulf Magnusson ulfalizer@gmail.com 2018-02-08T11:38:03Z urn:sha1:e2c2eef8902338f2c7fbff21d040fcf9a4953a8b It's the top-level Kconfig file that source's depending on $SRCARCH, not the top-level Makefile. 2018-02-08T10:03:33Z Ulf Magnusson ulfalizer@gmail.com 2018-02-08T10:03:33Z urn:sha1:fed0cb5133a4ddf470aa9a4e869a99ad6f0dc65d 2018-02-08T09:14:48Z Ulf Magnusson ulfalizer@gmail.com 2018-02-08T05:03:44Z urn:sha1:e8b4ecb6ff6ccc1c7be0818314fbccda2ef2b2ee Previously, setting a choice symbol to y would only update user_selection on the parent choice and not the symbol's own user_value. Now both are updated. The point of the old behavior was to remember the m mode selections of a choice when it was switched back and forth between m and y mode, which was a feature I thought the C implementation had. On closer inspection, the C implementation never had that feature, though it might appear like it if you only make "lucky" changes (if you never select any symbols in y mode that were n in m mode). The new behavior is simpler and easier to understand: Symbol.user_value now always matches the value assigned in a .config file or via set_value(), provided the value was well-formed. This might avoid some special-casing in scripts too. The loss in usability is pretty minimal. 2018-02-07T02:55:56Z Ulf Magnusson ulfalizer@gmail.com 2018-02-07T01:30:16Z urn:sha1:f66cd7155158943987570937be37b09d9ca58028 More experience working with the API convinced me that it's worth it. Gets rid of ugly conversions in the menuconfig.py and oldconfig.py examples, and streamlines some things internally as well. Include two other small fixes as well: - Make warnings generated by Choice.set_value() match those generated by Symbol.set_value(). - Get rid of the input stripping in menuconfig.py. It's not like the interface is usable as-is anyway, and it just complicates the example. 2018-01-30T09:46:38Z Ulf Magnusson ulfalizer@gmail.com 2018-01-30T09:43:04Z urn:sha1:0eadd61c05c523a150721f9646e4d3f7cff58e5c Defining a choice symbol in multiple places to add some properties to it outside the choice seems to actually be done deliberately by MIPS, but it's almost guaranteed to be an error if the definition(s) outside the choice have a prompt (and so can be changed by the user there), so warn for that. 2018-01-29T13:43:49Z Ulf Magnusson ulfalizer@gmail.com 2018-01-29T13:43:31Z urn:sha1:3db12f728ec2d48640574133675bb01ca926d741 Never has en affect. 2018-01-29T13:26:01Z Ulf Magnusson ulfalizer@gmail.com 2018-01-29T12:58:38Z urn:sha1:d43d2e83a9dc96d86dfbc946516bc3090303dbd3 Mirrors a warning in the C implementation.