Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

From: Bill Davidsen
Date: Tue Feb 06 2007 - 13:05:52 EST


Matt Mackall wrote:
On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote:
There's no reason we shouldn't be able to do exactly that with config
symbols in Kconfig-land. The only difference is that we've got
slightly different semantics for our "depend" keyword. Things which
don't have their "depend" requirements met aren't offered as options.
Whereas "select" is "automatically pull in dependencies"
apt/yum-style.
Perhaps this is because there is a lacking keyword. The depends controls visibility, perhaps a "requires" could be used to provide advisory information which mean "these other things will be turned on if you build this feature."

"require" is a bad name as it's a synonym of "depend".

While we're at it, it would also be nice to be able to do:

$ kconfig enable ACPI
CONFIG_ACPI conflicts with CONFIG_APM
$ kconfig enable -F ACPI
disabling CONFIG_APM
$ kconfig disable SCSI
CONFIG_USB_STORAGE depends on CONFIG_SCSI
$ kconfig disable -f SCSI
disabling USB_STORAGE
$ make

I think depends and select provide this now, the postulated "requires" might make building the trees easier.

The above is all about having a scriptable command line interface so
that people don't need the broken sed + make oldconfig thing.

I didn't say that clearly, I meant that the information to do this was present, not the functionality.

Someone suggested that 'requires' was a synonym of 'depends on' and was a bad choice. I think the requirement is in fasct the same, what I was after was not to prevent visibility of the option as 'depends' does. And we still probably need depends to avoid way too many choices.

--
bill davidsen <davidsen@xxxxxxx>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/