Hi, Sam Ravnborg wrote:
> Found a slot to give it a spin: > 1) Did not apply cleanly to 2.5.31. Makefile caused a reject. > Other hunks went ok, but with an offset. You probably had other patches applied? > 2) When browsing in menuconfig the menus are repositioned depending of > the length of the menu lines - irritating. > Using this in pure text-mode 80X25. That's the standard kernel lxdialog, I'm not intending to change anything in there. > 3) The tag (NEW) disappear first time you touch an option. It's not new anymore, the user has seen it, so why keep it? > 4) ISDN part is missing. What's missing? > 5) Tried to delete endmenu on line 610 in arch/i386/config.in: > ./scripts/lkc/mconf arch/i386/config.new > <none>:0:parse error > This error message is not good enough. Known problem, but it's currently not very high on my TODO list. > I would like to see the language extended with some rules ala: > "A statement shall be opened and closed in the same file." > This would make it trivial when reacing end-of-file to check if there is > any pending statements. I have no idea how much will break if this > is enforced. Greg's gcml may be the best tool to investigate that - Greg? Such check is simple to add. > General > > I dislike the requirement to convert all existing config.in files to > support the new syntax. You already have the machinery to do the > conversion online as needed, so why not detect if config.in is newer > than config.lkc and if thats the case regenerate config.lkc. > Then the different sub-systems and architectures could transform to > the new syntax as they wish. > As we can see with designated initialisers that will happen over a > relatively short period of time - but the maintaneres will bring the > changes to Linus. If it were possible to mix both syntax, I would do it, but changing to a new syntax has to be done at once. > Linus asked for fast compilation. I will suggest removing -O2. The speed > gained in execution can well be lost in compiling. It hasn't to be done that often and it's not that much anyway. > For the next patch you should consider integrating it with kbuild. That's > anyway where you will end up if it should go in the kernel. That was in the rejected patch. :) I'm about to release a new version, which is even better integrated and is even faster. bye, Roman ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
