On Tue, 2010-07-13 at 17:21 -0600, Grant Likely wrote:

On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker [off-list ref] wrote:

quoted

On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:

quoted

- I haven't figured out a way for the fragment to force an option to
  be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
  This may require changing the syntax.
- It still doesn't resolve dependencies.  A solver would help with this.
  For the time being I work around the problem by running the generated
  config through 'oldconfig' and looking for differences.  If the files
  differ (ignoring comments and generateconfig_* options) after oldconfig,
  then the <board>_defconfig target returns a failure.  (but leaves the
  new .config intact so the user can resolve it with menuconfig).  This
  way at least the user is told when a Kconfig fragment is invalid.

The solver would fix the whole issues with the defconfigs , we wouldn't
need this Kconfig change .. From my perspective we shouldn't be fooling
around with anything but the solver approach ..

The solver would complement Kconfig fragments, but it doesn't
implement all the functionality.  For instance, it doesn't help a
board config picking up a bunch of options from an SoC or Architecture
config file, especially things that are developer/maintainer choices
as opposed to hard requirements).  Solver on its own is an incremental
improvement over what we currently have, but it doesn't solve the
whole problem.

I don't understand what your saying here.. Imagine a defconfig that you
have now only drastically smaller. The solver picks the stuff that
doesn't exist already in the defconfig. You would just apply the solver
to whatever is in the defconfig.

Then that allows us to keep the current defconfig format without mass
converting to something else. It's would also be built on a solver that
helps with other issues within Kconfig.

quoted

It just doesn't feel like Kconfig was meant to do this, it feel like
somewhat of an abuse ..

Why?  It uses the Kconfig language itself to specify additional
constraints on the final configuration.  Seems to be the essence of
elegance to me.  :-)

To my mind the only problem with the current defconfig formatting is the
size of the files. If those files are 5-10 lines instead of 2000 lines,
then I think the readability problem isn't really an issue any more..

The point of using Kconfig was the readability..

Daniel

-- 
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.