On Tue, Aug 27, 2002 at 02:24:40AM +0200, Roman Zippel wrote:
> To install simply run 'make install KERNELSRC=<..>' and to uninstall
> 'make uninstall KERNELSRC=<..>', only 'make [oldconfig|config|menuconfig|
> xconfig]' is implemented right now, but the rest is easy to do. I tested
> it only against 2.5.31/i386, but other versions should work as well, as
> long as the rulebase is ok.
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.
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.
3) The tag (NEW) disappear first time you touch an option.
4) ISDN part is 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.
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?
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.
The syntax I sort of like, it's more readable than the old one.
But I would like those who are better familiar with the old syntax
to comment on this as weel. May the new syntax is simply not
powerfull enough??
Linus asked for fast compilation. I will suggest removing -O2. The speed
gained in execution can well be lost in compiling.
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.
Sam
-------------------------------------------------------
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
