From: Paul Bolle <pebolle@tiscali.nl>
To: Valentin Rothberg <valentinrothberg@gmail.com>
Cc: akpm@linux-foundation.org,
Stefan Hengelein <stefan.hengelein@fau.de>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7] checkkconfigsymbols.sh: reimplementation in python
Date: Mon, 29 Sep 2014 14:45:11 +0200 [thread overview]
Message-ID: <1411994711.6334.57.camel@x220> (raw)
In-Reply-To: <CAD3Xx4+REZ4gy=q6ywDy=b6NXOvfSrBWHG9NCnQdQanMvB6pKw@mail.gmail.com>
On Mon, 2014-09-29 at 14:08 +0200, Valentin Rothberg wrote:
> On Mon, Sep 29, 2014 at 12:28 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> > On Sun, 2014-09-28 at 17:55 +0200, Valentin Rothberg wrote:
> >> (d) only checks files under version control ('git ls-files')
> >
> > (The shell script is .git unaware. If you happen to have one or more
> > branches with "Kconfig" in their name, as I do, it generates a lot of
> > noise on stderr.)
>
> Do you prefer to use os.walk() then?
It seems I was unclear: this described a problem with the shell script
and not a problem with your python rewrite.
> I just don't want to assume that
> the script is called in a clean tree. 'git ls-files' avoids to filter
> files. How do you solve this issue in your script?
This is getting off topic, but I choose to not care about the state of
the tree on disk. My script basically does "git ls-tree -r $SOME_TAG",
filters out symlinks, and generates a long list of (blob, path) pairs to
work with.
(You may remember from https://lkml.org/lkml/2014/9/26/485 that my
script uses git notes for each blob it parses. Different approach,
different pros and cons.)
> >> +STMT = r"^\s*(?:if|select|depends\s+on)\s+" + EXPR
> >
> > Could please make that "depends on"? Yes, it seems the yacc grammar
> > accepts any amount of whitespace, but that doesn't make it right to use
> > anything other than a single space. (Can the yacc grammar be tweaked to
> > see "depends on" as one, well, token?)
>
> I don't know if yacc can do that. Usually the lexer trims whitespaces.
> If I change the regex to "depends on", we will miss potential
> statements as Kconfig accepts multiple spaces between the "depends"
> and the "on".
Your choice. (The expectation behind my request is that bogus results
from this script might help catch uses of this misfeature. But every use
of "depends on" is currently sane, anyway.)
> >> +REGEX_SOURCE_FEATURE = re.compile(r"(?:D|\W|\b)+CONFIG_(" + FEATURE + r")")
> >
> > That should be "-D", because now you get a hit on
> > TPS6507X_ADCONFIG_CONVERT_TS
> >
> > and friends. What does \W do, by the way?
>
> (?:\W|\b)+[D]{,1}CONFIG_... will do the trick. "-D" would fail in
> getting DCONFIG_ in the build files. "\W" matches not "\w", which is
> [A-Za-z0-9_].
The joy of regular expressions! You now know what wrong, and you'll
surely come up with something better than my idea to fix it.
Thanks,
Paul Bolle
next prev parent reply other threads:[~2014-09-29 12:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-20 14:15 [PATCH] checkkconfigsymbols.sh: reimplementation in python Valentin Rothberg
2014-09-21 19:39 ` [PATCH v2] " Valentin Rothberg
2014-09-21 19:53 ` [PATCH v3] " Valentin Rothberg
2014-09-21 21:28 ` Paul Bolle
2014-09-22 7:43 ` Valentin Rothberg
2014-09-22 8:24 ` Paul Bolle
2014-09-22 8:45 ` Valentin Rothberg
2014-09-22 9:06 ` Paul Bolle
2014-09-22 14:58 ` [PATCH v4] " Valentin Rothberg
2014-09-23 16:45 ` Paul Bolle
2014-09-27 12:57 ` [PATCH v5] " Valentin Rothberg
2014-09-27 14:30 ` [PATCH v6] " Valentin Rothberg
2014-09-28 15:55 ` [PATCH v7] " Valentin Rothberg
2014-09-29 10:28 ` Paul Bolle
2014-09-29 12:08 ` Valentin Rothberg
2014-09-29 12:45 ` Paul Bolle [this message]
2014-09-29 14:47 ` Michal Marek
2014-09-29 16:21 ` Paul Bolle
2014-09-29 17:05 ` [PATCH v8] " Valentin Rothberg
2014-10-01 14:58 ` Michal Marek
2014-10-04 9:29 ` Valentin Rothberg
2014-10-08 13:39 ` Michal Marek
2014-10-19 15:30 ` Valentin Rothberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1411994711.6334.57.camel@x220 \
--to=pebolle@tiscali.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefan.hengelein@fau.de \
--cc=valentinrothberg@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).