On Fri, 07 Dec 2001 11:44:55 -0300, Horst von Brand
<[EMAIL PROTECTED]> wrote:
>John Cowan <[EMAIL PROTECTED]> dijo:
>
>[...]
>
>> You only need to learn Python if you are going to change the
>> CML2 compiler or interpreter, not if you are just changing
>> CML2.
>
>I did look around in CML1 when
John Cowan <[EMAIL PROTECTED]> dijo:
[...]
> You only need to learn Python if you are going to change the
> CML2 compiler or interpreter, not if you are just changing
> CML2.
I did look around in CML1 when I had some troubles way back. Turned out to
be my fault, or was fixed in the next patch,
On Thu, Dec 06, 2001 at 07:57:10PM -0500, Eric S. Raymond wrote:
> Rob Landley <[EMAIL PROTECTED]>:
> > P.S. Can we seperate "add new subsystem y prime" and "remove old subsystem
> > y". LIke the new and old SCSI error handling, which have been in the tree in
> > parallel for some time? Did I
Horst von Brand <[EMAIL PROTECTED]>:
> I just shudder when thinking that I'll have to learn yet another weird
> language to be able to hack on Linux... C, gcc-isms with asm() and all, a
> bit of CML1, now CML2, are OK; and now Python...
You will not need to use Pytho to learn CML2.
--
Rob Landley <[EMAIL PROTECTED]>:
> P.S. Can we seperate "add new subsystem y prime" and "remove old subsystem
> y". LIke the new and old SCSI error handling, which have been in the tree in
> parallel for some time? Did I hear Eric ever suggest removing the old
> configurator for 2.4? Anybod
On Thu, 6 Dec 2001 05:03:12 -0500,
Rob Landley <[EMAIL PROTECTED]> wrote:
>P.S. Can we seperate "add new subsystem y prime" and "remove old subsystem
>y". LIke the new and old SCSI error handling, which have been in the tree in
>parallel for some time? Did I hear Eric ever suggest removing t
Horst von Brand wrote:
> I just shudder when thinking that I'll have to learn yet another weird
> language to be able to hack on Linux... C, gcc-isms with asm() and all, a
> bit of CML1, now CML2, are OK; and now Python...
You only need to learn Python if you are going to change the
CML2 comp
> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
>> So has anyone had time to test the Python version 1.5 based CML2 that
>> was posted? Would that make it more acceptable?
Alan> For 2.5 its a great leap forward.
That was my thought when I saw the patch to make CML2 work with Python
1.5 i
On Thursday 06 December 2001 12:25 pm, Alan Cox wrote:
> > So has anyone had time to test the Python version 1.5 based CML2 that
> > was posted? Would that make it more acceptable?
>
> For 2.5 its a great leap forward. For 2.4 its irrelevant. Its simply not
> the way stable kernel trees are run,
On Thu, Dec 06, 2001 at 03:51:17PM -0300, Horst von Brand wrote:
> John Stoffel <[EMAIL PROTECTED]> said:
> > > "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
> >
> > >> So has anyone had time to test the Python version 1.5 based CML2 that
> > >> was posted? Would that make it more acceptabl
John Stoffel <[EMAIL PROTECTED]> said:
> > "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
>
> >> So has anyone had time to test the Python version 1.5 based CML2 that
> >> was posted? Would that make it more acceptable?
>
> Alan> For 2.5 its a great leap forward.
>
> That was my thought w
On Thursday 06 December 2001 11:49 am, Rik van Riel wrote:
> > It's insidious, isn't it?
>
> Yes, I agree the method you're using to smuggle CML2 into
> a stable kernel is insidious. Please stop it.
1) I'm not. You're getting your players confused.
2) I don't think Marcelo would take it, so I
On Thu, Dec 06, 2001 at 07:07:14PM +0100, Martin Dalecki wrote:
> John Stoffel wrote:
>
> > The requirement for python2 is a bit of a pain, but hey, for 2.5, it's
> > not a problem.
>
> It is just a BIT OF PAIN. It gives me more trouble than the trouble
> I have even with the insufficiencies of
John Stoffel wrote:
> The requirement for python2 is a bit of a pain, but hey, for 2.5, it's
> not a problem.
It is just a BIT OF PAIN. It gives me more trouble than the trouble
I have even with the insufficiencies of the current make system.
Basta.
_
Rik> IMHO it's not acceptable that people upgrading from one 2.4
Rik> kernel to the next will have to install Python 2 on their
Rik> machine.
So has anyone had time to test the Python version 1.5 based CML2 that
was posted? Would that make it more acceptable?
Rik> Security bugs are and will b
> So has anyone had time to test the Python version 1.5 based CML2 that
> was posted? Would that make it more acceptable?
For 2.5 its a great leap forward. For 2.4 its irrelevant. Its simply not the
way stable kernel trees are run, even for people who think they are above
the rules and tradition
On Wed, 5 Dec 2001, Rob Landley wrote:
> 3) The fact Linus was cc'd on this before I trimmed it suggests to me
> that people are still wishfully thinking that the battle they lost
> before the linux-kernel summit would just magically re-open at the
> last minute. It's not about the fact that rei
On Wed, 5 Dec 2001, Rob Landley wrote:
> > So anyone perfectly happy with an older distro that didn't
> > ship python2-and-whatever-else gets screwed when they want to
> > build a newer kernel. Nice.
>
> 1) Moving from 2.2->2.4, it wouldn't work at all without a newer compiler and
> newer modutil
On Tuesday 04 December 2001 12:43 pm, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no end.
>
On Tuesday 04 December 2001 03:20 pm, Richard B. Johnson wrote:
> FYI, I have never known a problem that python has solved, only
> changed.
The same could be said of C. By definition, any program that can be
expressed in C could have been done on paper in binary.
Rob
> > Thanks but NO thanks
>
> Then go help Greg Banks in his CML2-in-C project.
Why? The current system works fine for me!
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Greg Banks <[EMAIL PROTECTED]>:
>It seems my main contribution has been to provide
> Eric with incentive to clarify his language spec and speed up his parser.
Stimulus for which I have been deeply grateful.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
..every
Richard B. Johnson scripsit:
> FYI, I have never known a problem that python has solved, only
> changed.
The same can be said of computers in general.
--
John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED]
Please leave your values| Check your assumption
On Tue, Dec 04, 2001 at 06:30:45PM +0100, Christoph Hellwig wrote:
> On Tue, Dec 04, 2001 at 11:18:38AM -0600, Michael Elizabeth Chastain wrote:
> > As far as CML2 versus an mconfig-based solution, I am tilted towards CML2,
> > as it is simply a better language. I would be happy with either choic
[Cc: list trimmed]
Tom Rini wrote:
>
> [... The spec for CML2 is
> out there, and there's even a CML2-in-C project. If you don't want to
> use Python, go help (I believe Greg Banks is who ESR mentioned is in
> charge of it) that project out [...]
In charge of it? I *am* it. At least, I wa
On December 4, 2001 06:50 pm, Daniel Phillips wrote:
> On December 4, 2001 05:52 pm, Giacomo Catenazzi wrote:
> > I don't think esr changed non problematic rules, but one:
> > all rules without help become automatically dependent to
> > CONFIG_EXPERIMENTAL. I don't like it, but I understand why
>
On Wed, Dec 05, 2001 at 10:00:32AM +1100, Keith Owens wrote:
> On Tue, 4 Dec 2001 18:21:15 + (GMT),
> Alan Cox <[EMAIL PROTECTED]> wrote:
> >> make bzlilo modules modules_install: it would be a simble
> >> make install: (and you configure with CML1/CML2 what install
> >> means).
> >
> >How do
On Wed, 5 Dec 2001 00:05:53 +0100,
David Weinehall <[EMAIL PROTECTED]> wrote:
>Would it be easy to add hooks for make-rpm and make-kpkg and alike,
>as methods for make installable?
I don't want details for any packaging method in kbuild. kbuild's job
is to build and install the kernel, not wrap
On Tue, 4 Dec 2001, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
>
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no end.
> > ...
> > I'm
On Tue, Dec 04, 2001 at 08:53:11PM +0100, Dave Jones wrote:
> On Tue, 4 Dec 2001, David Weinehall wrote:
>
> > "So anyone happy with an older distro that didn't ship gcc-2.95.x, x > 2
> > gets screwed when they want to build a newer kernel. Nice."
>
> The difference being that recommended compil
On Tue, 2001-12-04 at 12:43, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
>
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no end.
> > ...
On Tue, 4 Dec 2001, Eric S. Raymond wrote:
> Alan Cox <[EMAIL PROTECTED]>:
> > > I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in
> > > 7.1, so the RPM-based distros like KRUD and Mandrake have had it for
> > > seven months. Debian had it before that.
> >
> > RH shippe
On Tue, Dec 04, 2001 at 06:43:17PM +0100, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
>
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no
On Tue, Dec 04, 2001 at 01:43:20PM -0500, Eric S. Raymond wrote:
> David Weinehall <[EMAIL PROTECTED]>:
> > Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar,
> > nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip,
> > wish, tcl/tk and possibly others. That'd surely shave
On Tue, 2001-12-04 at 13:01, Alan Cox wrote:
> Feel free. You'll find python v1. There is a very early python2 on the
> optional power tools CD that some folks will have but downloaders generally
> dont bother with.
Also, I don't think any version of RedHat has Tkinter 2.0 yet ...
Rober
On Tue, Dec 04, 2001 at 06:08:57PM +0100, RaúlNúñez de Arenas Coronado wrote:
> Hi Matthias :)
>
> >Creating a dependency on Python? Is a non-issue.
>
> Maybe for you. For me it *is* an issue. I don't like more and
> more dependencies for the kernel. I mean, if I can drop kbuild and
> ke
On Tue, 4 Dec 2001 18:21:15 + (GMT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>> make bzlilo modules modules_install: it would be a simble
>> make install: (and you configure with CML1/CML2 what install
>> means).
>
>How does it handle that when install means different things on each box of
>a set
> Are we not talking about the 2.5 kernel build tree? My understanding of the
> numbering of kernels is that the 2.4.x tree is stable; and the 2.5.x tree is
> the new development tree
Erik is talking about crapping in both trees, as opposed to 2.5 only
___
> > That's been the case all along, sans python2. Newer kernels need newer
> > tools. That's always been the case.
>
> Not during stable releases. In fact we've jumped through hoops several
times
> to try and keep egcs built kernels working
Are we not talking about the 2.5 kernel build tree? My u
> > So anyone perfectly happy with an older distro that didn't
> > ship python2-and-whatever-else gets screwed when they want to
> > build a newer kernel. Nice.
>
> That's been the case all along, sans python2. Newer kernels need newer
> tools. That's always been the case.
Not during stable rele
On 4 Dec 2001, Edward Muller wrote:
> That's been the case all along, sans python2. Newer kernels need newer
> tools. That's always been the case.
Between major versions yes. Not within the same stable release.
Dave
--
| Dave Jones.http://www.codemonkey.org.uk
| SuSE Labs
__
On Tue, 4 Dec 2001, David Weinehall wrote:
> "So anyone happy with an older distro that didn't ship gcc-2.95.x, x > 2
> gets screwed when they want to build a newer kernel. Nice."
The difference being that recommended compiler versions don't
change midway through a stable series. Neither should
Rik van Riel <[EMAIL PROTECTED]>:
> Ohhh, that sounds a lot like "I'm not the maintainer, I'm
> not responsible for the code I submit" ;)))
I will provide stable code and be responsible for its stability. It will be
Marcelo's call, not mine, on whether the strategic tradeoffs come out
in favor
On Tue, 4 Dec 2001, Martin Dalecki wrote:
> "Eric S. Raymond" wrote:
> >
> > Alan Cox <[EMAIL PROTECTED]>:
> > > > Creating a dependency on Python? Is a non-issue. Current systems that
> > > > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > > > is nice and it does not
On Tue, 4 Dec 2001, Eric S. Raymond wrote:
> > Don't do it!
> > A stable kernel should be stable also on the building tools.
>
> That will be Marcelo's call, not mine.
Ohhh, that sounds a lot like "I'm not the maintainer, I'm
not responsible for the code I submit" ;)))
*runs like hell*
Rik
--
David Weinehall <[EMAIL PROTECTED]>:
> Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar,
> nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip,
> wish, tcl/tk and possibly others. That'd surely shave a lot of diskspace
> off my buildsystem. It's not like I use any of them
Tom Rini <[EMAIL PROTECTED]>:
> > Maybe for you. For me it *is* an issue. I don't like more and
> > more dependencies for the kernel. I mean, if I can drop kbuild and
> > keep on building the kernel with the old good 'make config' I won't
> > worry, but otherwise I don't think that kernel buil
On Tue, Dec 04, 2001 at 06:26:27PM +, Alan Cox wrote:
> > > > Python2 - which means most users dont have it.
> >
> > Most users sure as hell shouldn't be playing with 2.5.x right now
> > anyways. With any sort of 'luck' it'll be 6 months at least before
> > 2.5.x becomes stable enough that i
On Tue, Dec 04, 2001 at 07:00:37PM +0100, Giacomo Catenazzi wrote:
> I agree.
> In this manner distributions can also build a version that don't
> need python2 (IIRC the freeze tool convert python to C program
> which require only few python libs.
>
> Eric if you want I can build a .deb package i
On Tue, Dec 04, 2001 at 06:21:15PM +, Alan Cox wrote:
> > make bzlilo modules modules_install: it would be a simble
> > make install: (and you configure with CML1/CML2 what install
> > means).
>
> How does it handle that when install means different things on each box of
> a set of them NFS s
On Tue, Dec 04, 2001 at 06:08:57PM +0100, Ra?l N??ez de Arenas Coronado wrote:
> Hi Matthias :)
>
> >Creating a dependency on Python? Is a non-issue.
>
> Maybe for you. For me it *is* an issue. I don't like more and
> more dependencies for the kernel. I mean, if I can drop kbuild and
> k
On Tuesdayen den 4 December 2001 18.08, RaúlNúñez de Arenas Coronado wrote:
> Hi Matthias :)
>
> >Creating a dependency on Python? Is a non-issue.
>
> Maybe for you. For me it *is* an issue. I don't like more and
> more dependencies for the kernel. I mean, if I can drop kbuild and
> k
> > > Python2 - which means most users dont have it.
>
> Most users sure as hell shouldn't be playing with 2.5.x right now
> anyways. With any sort of 'luck' it'll be 6 months at least before
> 2.5.x becomes stable enough that it will probably compile all the time
> again and not have a random f
On Tue, Dec 04, 2001 at 06:27:26PM +0100, Martin Dalecki wrote:
> Alan Cox wrote:
> >
> > > Creating a dependency on Python? Is a non-issue. Current systems that
> > > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > > is nice and it does not create such unmaintainable
> make bzlilo modules modules_install: it would be a simble
> make install: (and you configure with CML1/CML2 what install
> means).
How does it handle that when install means different things on each box of
a set of them NFS sharing the kernel tree. This is a real world example
Michael Elizabeth Chastain wrote:
> [mailing lists trimmed]
>
> Christoph Hellwig writes:
>
>>Indepenand of wether 2.6 will use CML1 or CML2 I hope it won't ship with
>>the actual config tool. It's so much nicer to have mconfig compiled once
>>in /usr/bin instead of compiling menuconfig all th
On December 4, 2001 05:52 pm, Giacomo Catenazzi wrote:
> I don't think esr changed non problematic rules, but one:
> all rules without help become automatically dependent to
> CONFIG_EXPERIMENTAL. I don't like it, but I understand why
> he makes this decision.
I love it.
--
Daniel
_
"Eric S. Raymond" wrote:
>
> Alan Cox <[EMAIL PROTECTED]>:
> > > Creating a dependency on Python? Is a non-issue. Current systems that
> > > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > > is nice and it does not create such unmaintainable mess. Whether
> >
> > Pyth
Alan Cox wrote:
>
> > Creating a dependency on Python? Is a non-issue. Current systems that
> > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > is nice and it does not create such unmaintainable mess. Whether
>
> Python2 - which means most users dont have it.
And th
> > RH shipped python2 beginning RH 7.2.
>
> Eh? I'm going to go check my old 7.1 CDs...
Feel free. You'll find python v1. There is a very early python2 on the
optional power tools CD that some folks will have but downloaders generally
dont bother with.
Trust me, I went through the same pain w
[EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> It's not the CML1 language spec that interests me, just the user
> interface. All I care about is being able to do make menuconfig and
> make oldconfig, and get the same results as before. What goes on
> "under the surface" doesn't interest me at all.
>
[mailing lists trimmed]
Christoph Hellwig writes:
> Indepenand of wether 2.6 will use CML1 or CML2 I hope it won't ship with
> the actual config tool. It's so much nicer to have mconfig compiled once
> in /usr/bin instead of compiling menuconfig all the time in the tree.
I agree, it's really a
Alan Cox <[EMAIL PROTECTED]>:
> > I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in
> > 7.1, so the RPM-based distros like KRUD and Mandrake have had it for
> > seven months. Debian had it before that.
>
> RH shipped python2 beginning RH 7.2.
Eh? I'm going to go check
[EMAIL PROTECTED] wrote:
>
> In fact, here's all I want to know about the whole CML2/kbuild 2.5 issue. Right
> now I upgrade my kernel like this (simplified slightly):
>
>
> mv .config ..
> make mrproper
> mv ../.config .
> make oldconfig
> make dep
> make bzlilo modules modules_install
>
>
Alan Cox <[EMAIL PROTECTED]>:
> > Creating a dependency on Python? Is a non-issue. Current systems that
> > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > is nice and it does not create such unmaintainable mess. Whether
>
> Python2 - which means most users dont have
[EMAIL PROTECTED] said:
> I'm listening...what can I do for you?
Simply assure me that I don't have to scan every line of the CML2 files for
such changes, and that you'll make a reasonable effort to make the first set
of CML2 rules match the existing CML1 behaviour, without introducing any
cont
I suppose a polite title for me would be "maintainer emiritus"
of make config, make menuconfig, and make xconfig.
I'm in favor of abandoning the current tools because:
It's 3x maintenance to have 3 parsers for the same language.
It's difficult to do good syntax checking in scripts/Configure
David Woodhouse <[EMAIL PROTECTED]>:
> I do have objections to some of the other ideas which have been floated for
> changing the behaviour of the config rules, which aren't strictly related to
> the change in language.
I'm listening...what can I do for you?
--
http://www.tuxedo
[EMAIL PROTECTED] said:
> No, it's CONFIG_EXPERT. And this change is not wired in. Comment
> out this declaration in the top-level rulesfile:
> condition nohelp on EXPERT
> and it reverts to old behavior.
Good. Please make that the default when submitting the first version of
CML2. You ca
David Woodhouse <[EMAIL PROTECTED]>:
>
> [EMAIL PROTECTED] said:
> > I don't think esr changed non problematic rules, but one: all rules
> > without help become automatically dependent to CONFIG_EXPERIMENTAL. I
> > don't like it, but I understand why he makes this decision.
>
> That is precise
Giacomo Catenazzi <[EMAIL PROTECTED]>:
> I don't think esr changed non problematic rules, but one:
> all rules without help become automatically dependent to
> CONFIG_EXPERIMENTAL. I don't like it, but I understand why
> he makes this decision.
No, it's CONFIG_EXPERT. And this change is not wire
Matthias Andree <[EMAIL PROTECTED]>:
> Seriously: what do you fear? Losing the efforts you put into mconfig?
> Linux 2.2 and 2.4 will be around for quite some time (not sure about
> mconfig on 2.0, I don't use 2.0.x ATM).
Oops. I wasn't going to tell anyone this yet, but since you've made
this a
> Creating a dependency on Python? Is a non-issue. Current systems that
> are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> is nice and it does not create such unmaintainable mess. Whether
Python2 - which means most users dont have it.
__
[EMAIL PROTECTED] said:
> I don't think esr changed non problematic rules, but one: all rules
> without help become automatically dependent to CONFIG_EXPERIMENTAL. I
> don't like it, but I understand why he makes this decision.
That is precisely the kind of bogus change which should _not_ be d
David Woodhouse wrote:
>
> I do have objections to some of the other ideas which have been floated for
> changing the behaviour of the config rules, which aren't strictly related to
> the change in language.
The rules are nearly the same (but written in another language).
The problem was in c
[EMAIL PROTECTED] said:
> You can spend all week telling us how easy it would be to implement
> all the CML2 benefits that CML1 doesn't have, if you like -- but one
> of the rules of this game is that an ounce of working code beats a
> pound of handwaving.
FWIW I have no particular problem wit
Christoph Hellwig <[EMAIL PROTECTED]>:
> With mconfig [side-effect chasing] can be implemented easily [...]
> One toplevel config file can be implemented in CML1 easily,
You can spend all week telling us how easy it would be to implement
all the CML2 benefits that CML1 doesn't have, if you like -
On Tue, Dec 04, 2001 at 02:29:58PM +0100, Christoph Hellwig wrote:
> On Tue, Dec 04, 2001 at 08:16:40AM -0500, Eric S. Raymond wrote:
> > N separate implementations means N dialects and N**2 compatibility problems.
> > Nicer just to have *one* parser, *one* compiler, and *one* service class that
>
On Tue, Dec 04, 2001 at 08:16:40AM -0500, Eric S. Raymond wrote:
> N separate implementations means N dialects and N**2 compatibility problems.
> Nicer just to have *one* parser, *one* compiler, and *one* service class that
> supports several thin front-end layers, yes? No?
Oh man. When you thi
Christoph Hellwig <[EMAIL PROTECTED]>:
> There is a CML1 language specification, as written down in a file, namely
> Documentation/kbuild/config-language.txt in the kernel tree.
A specification which, according to its author, is incomplete.
> There is one tool (mconfig) which has a yacc-parser t
On Tue, Dec 04, 2001 at 07:48:15AM -0500, Eric S. Raymond wrote:
> And, by the way, there is no CML1 :-). Instead, there are four
> mutually incompatible dialects and a rulebase that breaks in different
> ways depending on which interpreter you use. Well, maybe just three
> mutual incompatible d
Christoph Hellwig <[EMAIL PROTECTED]>:
> There is no CML1 maintainer. There are people maintaining the different
> tools intepreting CML1. Some (e.g. the intree ones) are to ugly to consider,
> others are pretty nice.
I was referring to Michael Elizabeth Chastain, Keith Owens, and the other
peo
On Tue, Dec 04, 2001 at 07:28:08AM -0500, Eric S. Raymond wrote:
> Christoph Hellwig <[EMAIL PROTECTED]>:
> > On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote:
> > > The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
> >
> > Is the CML2 merge actually agreed on?
>
> Ye
Christoph Hellwig <[EMAIL PROTECTED]>:
> On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote:
> > The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
>
> Is the CML2 merge actually agreed on?
Yes, unless Linus has changed his mind since March. Which would be his
privilege
Alan Cox <[EMAIL PROTECTED]>:
> > Unfortunately, the syntax of CML1 is rebarbative, and its imperative
> > semantics cannot be mechanically translated to CML2's declarative
> > semantics by any means I'm aware of.
>
> The dependancy tree from CML1 is not that hard to obtain. It's not quite
> co
> Unfortunately, the syntax of CML1 is rebarbative, and its imperative
> semantics cannot be mechanically translated to CML2's declarative
> semantics by any means I'm aware of.
The dependancy tree from CML1 is not that hard to obtain. It's not quite
complete or correct though
> Is it not possible to write an automatic conversion tool that reads the
> existing CML1 files and outputs CML2 rules with identical behaviour?
Bad ones - yes. Its also possible to do everything CML2 does with the CML1
ruleset. All the information required is there. Howeve CML1 (all 4 dialects
On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote:
> The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
Is the CML2 merge actually agreed on?
I still strongly object to it and I know lots of kernel hackers are
the same opinion.
Christoph
--
Of course it doesn'
David Woodhouse <[EMAIL PROTECTED]>:
>
> [EMAIL PROTECTED] said:
> > The schedule I heard from Linus at the kernel summit was that both
> > changes were to go in between 2.5.1 and 2.5.2. I would prefer
> > sooner than later because I'm *really* *tired* of maintaining a
> > parallel rulebase.
[EMAIL PROTECTED] said:
> The schedule I heard from Linus at the kernel summit was that both
> changes were to go in between 2.5.1 and 2.5.2. I would prefer
> sooner than later because I'm *really* *tired* of maintaining a
> parallel rulebase.
Is it not possible to write an automatic conver
On Tue, 4 Dec 2001 01:22:52 +0100 (CET),
Dave Jones <[EMAIL PROTECTED]> wrote:
>Do you plan to fix the x2 slowdown before removing kbuild 2.4 ?
>Or is this something that will be worked on as we progress through 2.5.
It will be worked on during 2.5. I don't have time to rewrite the core
code _a
On Mon, 3 Dec 2001, Keith Owens wrote:
Hi Keith,
> _If_ I can get CML2 support working before 2.5.1 comes out then we go
> 2.5.2-pre1 Add kbuild 2.5 with both CML1 and CML2 support.
> 2.5.2-pre2 Remove kbuild 2.4.
Do you plan to fix the x2 slowdown before removing kbuild 2.4 ?
Or is this so
On Sun, 2 Dec 2001 20:19:46 -0500,
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
>Keith Owens <[EMAIL PROTECTED]>:
>> The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
>
>The schedule I heard from Linus at the kernel summit was that both changes
>were to go in between 2.5.1 and 2
Keith Owens <[EMAIL PROTECTED]>:
> Linus, the time has come to convert the 2.5 kernel to kbuild 2.5. I
> want to do this in separate steps to make it easier for architectures
> that have not been converted yet.
>
> 2.5.1 Semi-stable kernel, after bio is working.
>
> 2.5.2-pre1 Ad
Linus, the time has come to convert the 2.5 kernel to kbuild 2.5. I
want to do this in separate steps to make it easier for architectures
that have not been converted yet.
2.5.1 Semi-stable kernel, after bio is working.
2.5.2-pre1 Add the kbuild 2.5 code, still using Makefile-2.5
95 matches
Mail list logo
