Hi,

On Tue, Jun 18, 2013 at 10:44:52AM +0200, Michal Marek wrote:

quoted

On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote:

quoted

quoted

quoted

quoted

Sam Ravnborg (the kconfig ex-maintainer) once wrote that
he doesn't want to extend the kconfig language for this
purpose (which I support). That a config option is fine and
sufficient in this case [1]. Except he called the config
option "SHOW_ALL_DRIVERS". Adding the current maintainer to
CCs ;).

I agree with Sam. 'depends on XY || COMPILE_TEST' is quite 
self-explanatory. And even if it's not, you can look up the
help text for COMPILE_TEST. With "archdepends on" or
"available on", you need to know what to look for to override
the dependency.

you will still end up with:

depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI ||
ARCH_PPC || ...)

And every now and again that particular line will be updated
to add another arch dependency.

But that is perfectly fine *when* the driver is supported on
those archs only.

And come on, how much often will this "every now and again"
happen? We don't have that much cases where a driver is augmented
to work on another arch or platform. It either works on all of
them => doesn't need COMPILE_TEST, or work on one or two arches
at most.

MUSB alone has 8 different arch choices. Before, it used to be that
core driver was dependendent on all of them, so whenever someone
wanted to build MUSB for another arch, they had to introdude their
glue code and modify the dependency of the core driver.

But that you have complex dependencies in some drivers is mostly
orthogonal to the two choices of syntax, isn't it?

depends on ARCH1 || ARCH2 || .... || ARCH8 || COMPILE_TEST

vs.

archdepends on ARCH1 || ARCH2 || .... || ARCH8

right, but my argument is that I rather not have either. Depend on PCI
if you us PCI, depend on EXTCON if you use extcon, but no driver should
have an ARCH dependency. Specially since it lets people include mach/*
and asm/* headers because "it doesn't break compilation for anyone".

-- 
balbi