[<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