[Cocci] [PoC] coccinelle: make Coccinelle-related make targets more fine-grained
jrnieder at gmail.com
Fri Aug 3 08:44:19 CEST 2018
Julia Lawall wrote:
> This was already possible. Make coccicheck is not supposed to be used
> with -j, but rather with J=n. That tells Coccinelle to parallelize the
> treatment of the files internally. In this case, the semantic patch is
> only parsed once, and then n worker processes are forked to treat the
> different files.
Thanks for this hint.
I wonder if we can make this happen automatically under suitable
conditions. We can parse -j<num> out of MAKEFLAGS and convert it into a
J=<num> argument, but that only solves half the problem: the "make"
parent process would think that the coccinelle run only deserves to
occupy one job slot.
Technically we could do all this using a wrapper that pretends to be a
(prefixing the command with '+', parsing jobserver options from the
MAKEFLAGS envvar) but it gets ugly.
It's likely that the best we can do is just to advertise J more
>> On Thu, Aug 02 2018, Jeff King wrote:
>>> cat contrib/coccinelle/*.cocci >mega.cocci
>>> make -j40 coccicheck COCCI_SEM_PATCHES=mega.cocci
> There was already a COCCI=foo.cocci argument to focus on a single semantic
> I'm surprised that the above cat command would work. Semantic patch rules
> have names, and Coccinelle will not be happy isf two rules have the same
Yes, Git's semantic patches (in contrib/coccinelle) tend to be
> Some may also have variables declared in initializers, although
> perhaps the ones in the kernel don't do this. Causing these variables to
> be shared would not have a good effect.
... oh! You're thinking of the Linux kernel.
It looks like Linux's scripts/coccicheck has a lot we can crib from.
That's where the J envvar and automatic parallelism you mentioned are
So it sounds to me like at a minimum we should use all of that. ;-)
Thanks again for the pointers.
More information about the Cocci