Hi, On Mon, 1 Oct 2007, Oleg Verych wrote:
> Today's kconfig was proposed and accepted in a very unpleasant > circumstances, has very poor design, development and no working > alternative (for 5+ years now). If you want to make such statements, you have to offer a little more than the hot air you're producing right now... If you want to improve the design, you're more than welcome. I'm the first one to admit that there's still lots of room for improvement, but if you want to claim this can only be done via a rewrite, then you have to be a lot more specific what's wrong the current design and why it's unfixable. Quite some thought has been put into this design and if you were a little more specific, I could actually tell you why it is this way and maybe how to improve it incrementally instead of trying to reinvent everything. > + shell-like[0] (not like CML1, which is just shell) scripting, allowing > to extend easily (if there is no one available) capabilities, > config values or actions for particular sub-system or compilation > unit, Just to pick this one point as example: I like scripting and maybe I should just update the swig wrapper script I already have and merge it, which would make it easier to play with the kconfig database in whatever language you like. OTOH due to the necessary build dependencies I don't see this become a mandatory feature, so unless there is a compelling reason a certain set of base function will remain in C. bye, Roman ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
