Re: [kbuild-devel] Python 2.0 (from Debian) and CML2 1.3.3?
Jamie Fifield [EMAIL PROTECTED]: I've noticed some incompatibilities with CML2 1.3.3 and the Debian packaged Python 2.0 in woody. Is it safe to say that CML2 now requires Python 2.1? (If so, please update the weeeb page). Is there any possibility you were picking up a stray Python 1.5.2 binary in your path? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a A man with a gun is a citizen. A man without a gun is a subject. ___ 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
[kbuild-devel] Re: CML2 design philosophy heads-up
Jes Sorensen [EMAIL PROTECTED]: Not all cards have all features, not all users wants to enable all features. Yes, I understand that. You're not reading the derivations correctly. Let's take an example: derive MVME147_SCSI from MVME147 SCSI This doesn't turn on MVME147_SCSI on every MVME147 board. It turns on MVME147_SCSI when both MVME147 *and SCCI* are on. So to suppress MVME147_SCSI, one just leaves SCCI off. All these derived symbols will still be controllable. The difference is that instead of being controlled by a low-level hardware-oriented question they're controlled by a capability or subsystem symbol like SCSI, NET_ETHERNET, or SERIAL. 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. I'm in touch with Ray Knight directly and will fix this as he requests. 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. Does this mean you'll take over maintaining the CML2 rules files for the m68k port, so I don't have to? That would be wonderful. Reasoned objections can change my behavior. Grunting territorial challenges at me will not. You have two options: (1) persuade Linus that the whole CML2 thing is a bad idea and should be dropped, or (2) work with me to correct any errors I have made and improve the system. Growling at me and hoping I go away won't work, not when I've invested a year's effort in this project. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a As with the Christian religion, the worst advertisement for Socialism is its adherents. -- George Orwell ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
