lkml.org 
[lkml]   [2007]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
    On 7/21/07, Oleg Verych <olecom@flower.upol.cz> wrote:
    > * Date: Tue, 17 Jul 2007 16:08:54 +0200
    > >
    > > From: Mike Frysinger <vapier@gentoo.org>
    > >
    > > 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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-07-21 10:31    [W:0.025 / U:63.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site