Re: Why don't we separate menuconfig from the kernel?

[Sam Ravnborg <sam@ravnborg.org>]

On Sat, Sep 17, 2005 at 06:53:55PM -0700, Martin Fouts wrote:
> I don't have a patch yet, but I've just spent a bit of time looking at
> how kbuild works, and I believe there is a fairly straightforward way to
> keep kbuild in the kernel tree but make it easy to split it out so that
> someone could use it as a separate tool.
> 
> If this idea, appropriately modified, makes sense, I'll spend a bit of
> time to do a patch and set it up.
> 
> The basic idea is that kbuild stays in the kernel source tree, but a
> simple script is used to grab a copy of it out of the tree.  That copy
> is maintained as a separate "build/configuration" package, and the
> maintainer (yes, I'm volunteering) would keep the two versions in (near)
> sync.
> 
> After a quick glance, it looks like one would want to copy
> 
> Documentation/kbuild/*
> Scripts/kconfig/*
> Makefile
> 
> To this new copy.  The only real work to get started, it appears, and
> the reason why I'd rather have a discussion before I start, would be to
> split the toplevel Makefile up a bit, so that the 'pure kbuild' bits
> were moved into an include file. It's really that include file, not the
> toplevel Makefile that would need to be copied.
> 
> I suggest doing this because most of the make-related knowledge about
> kbuild itself is in that Makefile, but non-kernel users would not want
> the kernel specific targets.
> 
> I know of two other packages (busybox and ptxdist) that use kconfig now,
> and have been contemplating it for some of my projects, as well, so I'm
> interested enough to take the project on.
I'm a bit confused.
Do you want to take a copy of kbuild or kconfig?

kbuild is much more intiminate than kconfig althougth the latter has a
few kernel only issues too.

	Sam