Has it been decided not to put in CML2 into 2.5.x? I haven't seen much
talk of it (besides the patch being taken out of kbuild 2.5 and ESR
dropping off the list). Also I have not seen any word of it on Guillaume
Boissiere's 2.5 kernel status page. I had thought that and the new kbuild
(by Keith Owens) were suppose to be in the kernel since 2.5.1.
Hayden A. James
Computer Engineering
Stevens Institute of Technology
http://attila.stevens-tech.edu/~hjames/
> Has it been decided not to put in CML2 into 2.5.x? I haven't seen much
> talk of it (besides the patch being taken out of kbuild 2.5 and ESR
> dropping off the list). Also I have not seen any word of it on Guillaume
> Boissiere's 2.5 kernel status page. I had thought that and the new kbuild
> (by Keith Owens) were suppose to be in the kernel since 2.5.1.
OOoooh, ouch. You apparently missed the two (or more) significant flamewars
on these topics. The current status is that kbuild will probably slowly be
merged by going through Kai and being munged into Linus-acceptable patches,
while CML2 will probably sit around and never get merged unless ESR accepts
the fact that cool code solving a problem doesn't automagically get into
the kernel.
See the thread rooted somewhere around here ("Disgusted with Kbuild..."):
http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.2/0000.html
-Eric
--
------------------------------------------------
Eric H. Weigle -- http://public.lanl.gov/ehw/
------------------------------------------------
Hi,
On Thu, 20 Jun 2002, Hayden James wrote:
> Has it been decided not to put in CML2 into 2.5.x? I haven't seen much
> talk of it (besides the patch being taken out of kbuild 2.5 and ESR
> dropping off the list).
Due to the silence of him, we must assume that he has given up. CML2 has
a few problems, which make it unlikely that it gets included as is.
Anyway, not all hope is lost, I started my own configuration system some
time ago, which will be less complex than CML2. It's only advancing a bit
slowly currently, as I only have little time to work on it.
bye, Roman
On Fri, Jun 21, 2002 at 08:55:10PM +0200, Roman Zippel wrote:
> Anyway, not all hope is lost, I started my own configuration system some
> time ago, which will be less complex than CML2. It's only advancing a bit
> slowly currently, as I only have little time to work on it.
Hi Roman.
Despite the fact that you are advancing slowly could you explain what your plans
are with the configuration system?
As of today we have basically three different ways to read the Config.in files,
where xconfig are the one with the best but also most critical parser/analyser.
Do you plan to replace all of them or?
Have you planned to let CML1 and ZCONF(or whatever you planned to call the
new semantic) co-exist?
Sam
Hi,
On Sat, 22 Jun 2002, Sam Ravnborg wrote:
> Despite the fact that you are advancing slowly could you explain what your plans
> are with the configuration system?
>
> As of today we have basically three different ways to read the Config.in files,
> where xconfig are the one with the best but also most critical parser/analyser.
> Do you plan to replace all of them or?
My plan is to convert the current configuration into a new format (I have
a tool for that), which is more flexible and will allow that all needed
information to configure/build a driver is at a single place. It currently
looks like this:
config BLK_DEV_SD
depends SCSI
tristate "SCSI disk support"
help
If you want to use a SCSI hard disk ...
More information can be added later to this.
The current parsers will all be replaced with a single parser, actually
it's a library that does all the work and which allows multiple front
ends to behave identical.
bye, Roman