Re: [kbuild-devel] Re: Rename all derived CONFIG variables

2001-03-14 Thread Oliver Xymoron
On Mon, 12 Mar 2001, Keith Owens wrote: > On Mon, 12 Mar 2001 03:53:07 -0500, > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > >But if we're going to push Linus and the kernel crew to switch to > >CML2, then why invite the political tsuris of trying to get a large > >patch into 2.4 now? Maybe I'

Re: [kbuild-devel] Re: Rename all derived CONFIG variables

2001-03-12 Thread Alan Cox
> The derived config variables should be in a separate name space, > whether config is CML1 or CML2. This patch does it for CML1. Why ? The only tool that needs to seperate them is the config check script and that has enough information to deduce them - To unsubscribe from this list: send the

Re: Rename all derived CONFIG variables

2001-03-12 Thread Alan Cox
> Not only do I think that CONFIG_xxx_DERIVED needlessly extends the name > of derived vars, but your patch does not belong in a stable series. > Derived CONFIG_xxx vars are likely to be referenced in source. Changing > those vars in the middle of a stable series pointlessly breaks external > so

Re: Rename all derived CONFIG variables

2001-03-12 Thread Hugh Dickins
On Mon, 12 Mar 2001, Keith Owens wrote: > In 2.4.2-ac18 there are 130 CONFIG options that are always derived from > other options, the user has no control over them. It is useful for the > kernel build process to know which variables are derived and which > variables the user can control. If it'

Re: Rename all derived CONFIG variables

2001-03-12 Thread Philipp Rumpf
On Mon, Mar 12, 2001 at 06:03:22PM +1100, Keith Owens wrote: > In 2.4.2-ac18 there are 130 CONFIG options that are always derived from > other options, the user has no control over them. It is useful for the > kernel build process to know which variables are derived and which > variables the user

Re: [kbuild-devel] Re: Rename all derived CONFIG variables

2001-03-12 Thread Keith Owens
On Mon, 12 Mar 2001 03:53:07 -0500, "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: >But if we're going to push Linus and the kernel crew to switch to >CML2, then why invite the political tsuris of trying to get a large >patch into 2.4 now? Maybe I'm missing something here, but this doesn't >seem n

Re: [kbuild-devel] Re: Rename all derived CONFIG variables

2001-03-12 Thread Eric S. Raymond
Peter Samuelson <[EMAIL PROTECTED]>: > > In 2.4.2-ac18 there are 130 CONFIG options that are always derived > > from other options, the user has no control over them. > > I've thought about these before ... but never got around to doing > anything about them. I agree they should have a separate

Re: Rename all derived CONFIG variables

2001-03-12 Thread Peter Samuelson
[kaos] > In 2.4.2-ac18 there are 130 CONFIG options that are always derived > from other options, the user has no control over them. I've thought about these before ... but never got around to doing anything about them. I agree they should have a separate namespace. However, I would vote the f

Re: Rename all derived CONFIG variables

2001-03-11 Thread Jeff Garzik
Keith Owens wrote: > > In 2.4.2-ac18 there are 130 CONFIG options that are always derived from > other options, the user has no control over them. It is useful for the > kernel build process to know which variables are derived and which > variables the user can control. There are also 6 CONFIG

Rename all derived CONFIG variables

2001-03-11 Thread Keith Owens
In 2.4.2-ac18 there are 130 CONFIG options that are always derived from other options, the user has no control over them. It is useful for the kernel build process to know which variables are derived and which variables the user can control. There are also 6 CONFIG options that are not used anyw