Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Jakob == Jakob Østergaard [EMAIL PROTECTED] writes: Jakob On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: I think this is a very important point, and one I agree with. I tend to let my distribution handle stuff like python. now, I use RedHat's on-going devel, RawHide. it is not using python2. in fact, since switching to python2 may break old stuff, I don't expect python2 until 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et al, are written in python1 and they just are not going to change on someone's whim. Jakob 2.6.0 isn't going to happen for at least a year or two. What's Jakob the problem ? Jakob Want 2.5.X ? Get the tools too. Some people grab the latest devel kernels because thats all that works on their hardware. Jakob I'm in no position to push people around, but I think the Jakob whining about CML2 tool requirements is completely unjustified. Jakob If we required that everything worked with GCC 2.7.2 and nmake, Jakob where would we be today ? I'm a lot more worried about CML2 Jakob itself than about the tools it requires :) gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are not. Jakob Whether CML2 requires python2 or not, the distributions will Jakob change. This is not about Eric pushing something down people's Jakob throats. Tools evolve, and new revisions introduce Jakob incompatibilities, but distributions still follow the Jakob evolution. Nobody ships perl4 today either. The point is that Eric has been trying to push distributions to ship P2. Jes ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
John == John Cowan [EMAIL PROTECTED] writes: John Jes Sorensen wrote: Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. John Au contraire. It is very reasonable to have both python and John python2 installed. Having two different gcc versions installed John is a big pain in the arse. It's not unreasonable to have both installed, it's unreasonable to require it. Eric seems to think he can tell every distributor to ship Python2 tomorrow. Well it's a fine dream but it's not going to happen; Most distributors do not ship new major versions of tools in their minor number release versions. I've seen him mention the number 6 months until everybody ships it, but a) thats not going to happen Red Hat is currently at 7.1 (if one looks at their release history, one would say there is a good chance there will be a 7.2) not to mention the release rate of Debian (not sure about the current state of all other distributions). 18 months is more realistic for it to be deployed widely enough. So far I haven't heard a single developer say something positive about CML2, the most positive I have heard so far has been whatever, it's his choice, I don't care, I want to hack. The majority are of the NO! and you got to be kiddin'. John Anonymized hearsay evidence is less than convincing. Well I don't like to quote personal conversations without peoples' approval, now both David Woodhouse and Arjan are two examples. Jes ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Keith == Keith Owens [EMAIL PROTECTED] writes: Keith cc trimmed back to mailing lists only. On Fri, 18 May 2001 Keith 10:53:53 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: (a) Back off the capability approach. That is, accept that people doing configuration are going to explicitly and exhaustively specify low-level hardware. Keith No, you loose one of the nicer features of CML2. No, explicit selection *must* be available as an option. Jes ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Eric == Eric S Raymond [EMAIL PROTECTED] writes: Eric Jes Sorensen [EMAIL PROTECTED]: For a start, so far there has been no reason whatsoever to change the format of definitions. Eric The judgment of the kbuild team is unanimous that you are Eric mistaken on this. That's the five people (excluding me) who Eric wrote and maintained the CML1 code. *They* said that code had Eric to go, Linus has concurred with their judgment, and the argument Eric is over. Replacing the code does not require changing the style of the config files. Thats a major problem with CML2, you introduce a new 'let me do everything for you' tool that relies on a programming language that is not being shipped by any major vendor nor does it look like they are planning to do it anytime soon. And even if they start doing so, this is a totally unreasonable requirement, you *must* to make it possible to compile kernels on older distributions without requiring people to update half of their system. On some architectures, the majority of the users are still on glibc 2.0 and other old versions of tools. Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. Nobody disagrees that the Makefiles needs a redesign, however that doesn't mean everything else has to be redisigned in a totally incompatible manner. Eric If you persist in misunderstanding what I am doing, you are Eric neither going to be able to influence my behavior nor to Eric persuade other people that it is wrong. Listen carefully, Eric please: Oh I don't, on the other hand I see you consistently ignoring the needs and requirements of the users. So far I haven't heard a single developer say something positive about CML2, the most positive I have heard so far has been whatever, it's his choice, I don't care, I want to hack. The majority are of the NO! and you got to be kiddin'. Eric 1. The CML2 system neither changes the CONFIG_ symbol namespace Eric nor assumes any changes in it. (Earlier versions did, but Greg Eric Banks showed me how to avoid needing to.) Let's just say you didn't exactly give peoiple a good impression with the trolling around on how everybody had to change their option names and how important it was for the world. Eric 2. The ruleset changes I have made simplify the configuration Eric process, but they do *not* in any way restrict the space of Eric configurations that are possible. By design, every valid Eric (consistent) configuration in CML1 can be generated in CML2. I Eric treat departures from that rule as rulesfile bugs and fix them Eric (as I just did at Ray Knight's instruction). What spawned this recent discussion was you wanting to remove config options and automatically enable things instead of giving the users the explicit choice to do so. Now you are trying to tell me that you are not changing things? Eric 3. I do not have (nor do I seek) the power to impose anything Eric on anyone. We'll let that one stand on display for a few minutes. Eric You really ought to give CML2 a technical evaluation yourself Eric before you flame me again. Much of what you seem to think you Eric know is not true. So far I have had to deal with a number of requests from you trying to impose unreasonable changes on developers. Thats more than plenty for me. I do not have Python2 installed and I do not plan to, if you change CML2 to use a reasonable programming language I might give it a try. Jes PS: And if you could start making your .signature rfc1855 compliant it was be pleasant for all readers of this mailing list. ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
Eric == Eric S Raymond [EMAIL PROTECTED] writes: Eric I've said before on these lists that one of the purposes of Eric CML2's single-apex tree design is to move the configuration Eric dialog away from low-level platform- specific questions towards Eric higher-level questions about policy or intentions. Eric Or to put another way: away from hardware, towards capabilities. Eric As a concrete example, the CML2 rulesfile master for the m68k Eric port tree now has a section that looks like this: Eric # These were separate questions in CML1. They enable on-board Eric peripheral # controllers in single-board computers. derive Eric MVME147_NET from MVME147 NET_ETHERNET derive MVME147_SCC from Eric MVME147 SERIAL derive MVME147_SCSI from MVME147 SCSI derive Eric MVME16x_NET from MVME16x NET_ETHERNET derive MVME16x_SCC from Eric MVME16x SERIAL derive MVME16x_SCSI from MVME16x SCSI derive Eric BVME6000_NET from BVME6000 NET_ETHERNET derive BVME6000_SCC Eric from BVME6000 SERIAL derive BVME6000_SCSI from BVME6000 SCSI Not all cards have all features, not all users wants to enable all features. Eric # These were separate questions in CML1 derive MAC_SCC from MAC Eric SERIAL derive MAC_SCSI from MAC SCSI derive SUN3_SCSI from Eric (SUN3 | SUN3X) SCSI As Alan already pointed out thats assumption is invalid. Eric This is different from the CML1 approach, which generally Eric involved explicitly specifying each driver with mutual Eric dependencies described (if at all) in Configure.help. Yes and it should stay like that. If Richard had wanted all those features enabled per default when an MVME setting was selected, he would have done it in the config.in file, which is perfectly valid to do so today. Eric This note is a heads-up. If others with a stake in the Eric configuration system (port managers, etc.) have objections to Eric moving further in this direction, I need to hear about it, and Eric about what you think we should be doing instead. -- a Eric href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Yes I have objections. I thought I had made this clear a long time ago: Go play with another port and leave the m68k port alone. Thank you Jes ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
