Messages in this thread | | | Date | Tue, 4 Dec 2001 14:29:58 +0100 | From | Christoph Hellwig <> | Subject | Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5 |
| |
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 think one implementation of a 'standard' is better then multiple go to the MS world.
> > All of these tools just require the runtime contained in the LSB and no > > funky additional script languages. Also none needs a binary intermediate > > representation of the config. > > I quote Linus at the 2.5 kernel summit: "Python is not an issue." > Unless and until he changes his mind about that, waving around this > kind of argument is likely to do your case more harm than good.
For me (and others) it is an issues.
> If you want to re-open the case for saving CML1, you'd be better off > demonstrating how CML1 can be used to (a) automatically do implied > side-effects when a symbol is changed,
With mconfig it can be implemented easily - I don't see the point in doing it, though.
> (b) guarantee that the user > cannot generate a configuration that violates stated invariants, and
What do you mean with that?
> (c) unify the configuration tree so that the equivalents of arch/* > files never suffer from lag or skew when an architecture-independent > feature is added to the kernel.
One toplevel config file can be implemented in CML1 easily, using mconfig or the old and ugly tools, it's just a question of changeing the rule base in tree. At last Alan think multiple toplevel files are a feature, not a bug (I don't agree with him on that) so it's a completly separate discussion.
Christoph
-- Of course it doesn't work. We've performed a software upgrade. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |