Re: [kbuild-devel] linux kernel conf 0.3

2002-09-06 Thread Roman Zippel

Hi,

On Fri, 6 Sep 2002, Greg Banks wrote:

  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.

 I think this would be very useful if it were possible, as it would
 enable a gradual directory-by-directory switchover.  That is a clear
 requirement I believe.

Why should that be a requirement? You can already look now at the new
config files directory-by-directory, if anything is wrong with them, I'd
really like to hear it and I'll do my best to fix it.

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=sourceforge1refcode1=vs3390
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel



Re: [kbuild-devel] linux kernel conf 0.3

2002-09-06 Thread Sam Ravnborg

On Fri, Sep 06, 2002 at 03:45:45PM +1000, Greg Banks wrote:
 It seemed easy to add a check to gcml2 for if statements beginning
 and ending in the same file, so last night I did it.  The result is...
 zero such cases in 2.5.33.
The idea popped up when I noticed the missing endmenu in the 
appletalk/Config.in file recently.
mconfig bailed out with an syntax error in arch/i386/config.in or similar.
Thought it would be nice to point out where the actual error occured,
and the easiest implementation IMO was to check that all statements
opened in a file, was closed at end-of-file. And you proved it was easy 
at least in gcml2.

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=sourceforge1refcode1=vs3390
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel



Re: [kbuild-devel] linux kernel conf 0.3

2002-09-05 Thread Greg Banks

Sam Ravnborg wrote:
 
 On Tue, Aug 27, 2002 at 02:24:40AM +0200, Roman Zippel wrote:

Hi Roman, I really haven't had time to look at your release properly
yet, sorry.  I did notice though that the converter issues warnings
for dead code and comparisons of boolean variables to m, which I
thought was a good idea.

 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?

It seemed easy to add a check to gcml2 for if statements beginning
and ending in the same file, so last night I did it.  The result is...
zero such cases in 2.5.33.

 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.

I think this would be very useful if it were possible, as it would
enable a gradual directory-by-directory switchover.  That is a clear
requirement I believe.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.


---
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=sourceforge1refcode1=vs3390
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel



Re: [kbuild-devel] linux kernel conf 0.3

2002-09-04 Thread Sam Ravnborg

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=sourceforge1refcode1=vs3390
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel