On 7/21/07, Oleg Verych <[EMAIL PROTECTED]> wrote: > * Date: Tue, 17 Jul 2007 16:08:54 +0200 > > > > From: Mike Frysinger <[EMAIL PROTECTED]> > > > > The sed expression used at the moment in scripts/Makefile.headersinst > > relies on the (handy) GNU extension where you can escape ERE's in an > > otherwise BRE without using the GNU -r option. The following patch > > replaces this "\+" usage with a functionally equivalent POSIX BRE compliant > > "\{1,\}". > > Matching at least one occurrence, right?
that is the definition of both + and \{1,\} > > # Eliminate the contents of (and inclusions of) compiler.h > > OK, that means annotations and non ANSI 'inline' thing. Lets see. > > > HDRSED := sed -e "s/ inline / __inline__ /g" \ > [] > > - -e "s/[[:space:]]__attribute_const__[[:space:]]\+/\ /g" \ > > * [[:space:]] are more than tab and space isspace(3), is it more > effective to use [[:blank:]] instead? if you want to make some micro optimization in the build install step, sure ... but functionally, the difference is irrelevant considering sed operates only on individual lines > > + -e > > "s/[[:space:]]__user[[:space:]]\{1,\} > > substitute one or more ' __user ' > > > / /g" \ > > with ' ', everywhere (flag 'g'). So, is it really needed that '\{' thing? no, there is no grouping marker anywhere, so the match always applies to just the whitespace > > + -e "s/(__user[[:space:]]\{1,\}/ (/g" \ > > + -e "s/[[:space:]]__force[[:space:]]\{1,\}/ /g" \ > > + -e "s/(__force[[:space:]]\{1,\}/ (/g" \ > > + -e "s/[[:space:]]__iomem[[:space:]]\{1,\}/ /g" \ > > + -e "s/(__iomem[[:space:]]\{1,\}/ (/g" \ > > + -e "s/[[:space:]]__attribute_const__[[:space:]]\{1,\}/\ /g" \ > > -e "s/[[:space:]]__attribute_const__$$//" \ > > Is it allowed to use identifiers like '__attribute_const__foo' or > __attribute_const__[anything]? If it's not, last line is useless also. a question that i think is really only relevant if it actually occurs in the source code > > -e "/^\#include <linux\/compiler.h>/d" > whitespace is allowed ^ here and is used for better readability > sometimes. so post a patch for inclusion ... not that it's been an actual problem [yet] though -mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel