From: Greg Dietsche <gregory.dietsche@cuw.edu>
To: Julia Lawall <julia@diku.dk>
Cc: Nicolas Palix <Nicolas.Palix@inria.fr>,
rdunlap@xenotime.net, Gilles.Muller@lip6.fr, cocci@diku.dk,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] coccicheck: add M= option to control which dir is processed
Date: Sat, 11 Jun 2011 12:22:15 -0500 [thread overview]
Message-ID: <4DF3A447.3050505@cuw.edu> (raw)
In-Reply-To: <Pine.LNX.4.64.1106111740130.13465@ask.diku.dk>
On 06/11/2011 10:40 AM, Julia Lawall wrote:
> On Sat, 11 Jun 2011, Greg Dietsche wrote:
>
>
>> On 06/08/2011 02:10 PM, Nicolas Palix wrote:
>>
>>> I am not familiar with out-of-tree development but I guess that in
>>> that case we should
>>> also add a "-I $KBUILD_EXTMOD/include" ?
>>>
>>>
>>>
>> I decided to skip doing this in V2 of the patch. I did a very quick test and
>> cocci didn't seem to like two -I flags on one command line.
>>
> What was the problem and what version of coccinelle do you have? To my
> recollection, the ability to have multiple -I options was added sometime
> not so long ago.
>
>
Hmm... my 'quick' test must have been bad. I just tested again with
0.2.3 (debian squeeze) and 1.0.0-rc3 and both seem to work just with
multiple -I options. As I recall, originally, the script just exited
with a code of 1 in my original test...
so the updated line really should read:
OPTIONS="-dir $KBUILD_EXTMOD -patch $srctree -I $srctree/include -I
$KBUILD_EXTMOD/include"
I'll send an updated patch in a day or two. I've got some other stuff to
do today. Also, I noticed another bug that I'll need to fix too. The
lines in my patch that read:
echo 'M= is only supported for Coccinelle >= 0.2.3'
exit 1
are flat out wrong... :(
Greg
> julia
>
>
>>> The use of -I by Coccinelle depends on the other options (like
>>> -include_headers or -all_includes).
>>> Such options are retrieved from the comments in the cocci files.
>>> So the need for -I depends on the semantic patch you consider. I think
>>> it is thus better
>>> to be "exhaustive" in that case.
>>>
>>> Julia, is there any performance problem in doing so ?
>>>
>>>
>> Greg
>>
next prev parent reply other threads:[~2011-06-11 17:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 3:29 coccicheck: Add M= option Greg Dietsche
2011-06-08 3:29 ` [PATCH 1/2] coccicheck: add M= option to control which dir is processed Greg Dietsche
2011-06-08 19:00 ` Greg Dietsche
2011-06-08 19:10 ` Nicolas Palix
2011-06-11 15:29 ` [PATCH 1/2 V2] " Greg Dietsche
2011-06-11 15:33 ` [PATCH 1/2] " Greg Dietsche
2011-06-11 15:40 ` Julia Lawall
2011-06-11 17:22 ` Greg Dietsche [this message]
2011-06-11 17:53 ` [PATCH 1/2 v3] " Greg Dietsche
2011-11-04 1:17 ` Greg Dietsche
2011-06-08 3:29 ` [PATCH 2/2] coccinelle.txt: update documentation to include M= option Greg Dietsche
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=4DF3A447.3050505@cuw.edu \
--to=gregory.dietsche@cuw.edu \
--cc=Gilles.Muller@lip6.fr \
--cc=Nicolas.Palix@inria.fr \
--cc=cocci@diku.dk \
--cc=julia@diku.dk \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
/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