Re: [kbuild-devel] More effective processing (Re: [PATCH 25/33] kbuild: use POSIX BRE in headers install target)

2007-07-21 Thread Sam Ravnborg
On Sun, Jul 22, 2007 at 12:16:27AM +0200, Oleg Verych wrote:
 
 What do you think about this one? I want to propose to remove
 scripts/unifdef.c but to make clear policy about how to mark __KERNEL__
 sections in header files. We know how obfuscated C can be, and this also
 applies to preprocessing. There's known CodingStyle about some points.
 The thing is to specify rules, that will be easy for `sed` to do cleaup
 job.
 
 ./linux/soundcard.h:#if (!defined(__KERNEL__)  !defined(KERNEL)  
 !defined(INKERNEL)
!defined(_KERNEL)) || defined(USE_SEQ_MACROS)
 ./linux/stat.h:#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__  
 2)
 
 Split __KERNEL__ check, make only positive, i.e.
 
 #if defined(__KERNEL__)
 #ifdef __KERNEL__
 
 ./linux/stat.h:#ifdef __KERNEL__
 
 No `#else` and ending part to contain comment:
 
 ./linux/smb_fs_sb.h:#endif /* __KERNEL__ */
 
 Simple enough:
 
 sed '/^#if[^_]*__KERNEL__/,/^#end[^_]*__KERNEL__/d'

What are you trying to say with the above?
Sorry but I lost track of part of the discussion but you seems to havea point 
here?

Sam

-
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


Re: [kbuild-devel] More effective processing (Re: [PATCH 25/33] kbuild: use POSIX BRE in headers install target)

2007-07-21 Thread Mike Frysinger
On 7/21/07, Oleg Verych [EMAIL PROTECTED] wrote:
 On Sat, Jul 21, 2007 at 10:39:16PM +0200, Sam Ravnborg wrote:
  On Sat, Jul 21, 2007 at 03:21:43PM -0400, Mike Frysinger wrote:
 []
   while you could try and make a claim against memory/cpu effeciency, i
   fail to see how the first or last claims could possibly be backed up

 Less \{\(\\n\t\+\)\} [0] stuff make readings regex much easier. My
 confusion shows that i didn't used \{ much, because have another ways
 so far. And even after my quick testing i didn't realize that there
 was unrelated to main task whitespace cleanup.

the e-mail text you were quoting was [[:blank:]] vs [[:space:]], not + vs \{1,\}

 ./linux/stat.h:#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__  
 2)

__GLIBC__ cruft should be cleansed rather than looked at for anything else
-mike

-
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


Re: [kbuild-devel] More effective processing (Re: [PATCH 25/33] kbuild: use POSIX BRE in headers install target)

2007-07-21 Thread Oleg Verych
On Sun, Jul 22, 2007 at 12:13:26AM +0200, Sam Ravnborg wrote:
 On Sun, Jul 22, 2007 at 12:16:27AM +0200, Oleg Verych wrote:
  
  What do you think about this one? I want to propose to remove
  scripts/unifdef.c but to make clear policy about how to mark __KERNEL__
  sections in header files. We know how obfuscated C can be, and this also
  applies to preprocessing. There's known CodingStyle about some points.
  The thing is to specify rules, that will be easy for `sed` to do cleaup
  job.
  
  ./linux/soundcard.h:#if (!defined(__KERNEL__)  !defined(KERNEL)  
  !defined(INKERNEL)
 !defined(_KERNEL)) || defined(USE_SEQ_MACROS)
  ./linux/stat.h:#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ 
   2)
  
  Split __KERNEL__ check, make only positive, i.e.
  
  #if defined(__KERNEL__)
  #ifdef __KERNEL__
  
  ./linux/stat.h:#ifdef __KERNEL__
  
  No `#else` and ending part to contain comment:
  
  ./linux/smb_fs_sb.h:#endif /* __KERNEL__ */
  
  Simple enough:
  
  sed '/^#if[^_]*__KERNEL__/,/^#end[^_]*__KERNEL__/d'
 
 What are you trying to say with the above?
 Sorry but I lost track of part of the discussion but you seems to havea point 
 here?

I want to suggest more easy and tools-friendly way of processing header
files in the headrer_install target. One line above, one paragraph in
CodingStyle, one tree revision from KJ group.


-
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