[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080213084541.GA8091@uranus.ravnborg.org>
Date: Wed, 13 Feb 2008 09:45:41 +0100
From: Sam Ravnborg <sam@...nborg.org>
To: David Miller <davem@...emloft.net>
Cc: greg@...ah.com, torvalds@...ux-foundation.org, jeff@...zik.org,
arjan@...radead.org, sfr@...b.auug.org.au,
linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
linux-arch@...r.kernel.org, akpm@...ux-foundation.org,
linux-kbuild <linux-kbuild@...r.kernel.org>
Subject: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
>
> 2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
> instead have each "thing" have it's own Kconfig.foo or
> Makefile.foo that gets automatically sucked into the main
> directory Makefile or Kconfig using file globs or similar.
So we could do:
config foo
tristate "do you want foo?"
depends on USB && BAR
module
obj-$(CONFIG_FOO) += foo.o
foo-y := file1.o file2.o
help
foo will allow you to explode your PC
The [module] part would go unedited into a kbuild file
located in same dir as the Kconfig file and included by kbuild.
That would solve the Makefile issue.
And we could introduce support for
source "drivers/net/Kconfig.*"
But then we would have to make the kconfig step mandatory
for each build as we would otherwise not know if there
were added any Kconfig files.
Does this fit what you had in mind?
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists