All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: cocci@inria.fr
Subject: [cocci] Is there a --no-includes --but-includet-this foo.h --but-in[...] mode?
Date: Tue, 16 Nov 2021 14:27:41 +0100	[thread overview]
Message-ID: <211116.86lf1op65q.gmgdl@evledraar.gmail.com> (raw)

[First time poster, long time spatch user, thanks a lot for providing
it!]

I'm trying to optimize the runtime of spatch in git.git by leveraging
information that's already in the Makefile. Both GCC and Clang know how
to spew out information about what headers a given file depends on in
"Makefile" format, e.g. for a "hook.c" in git.git:
    
    $ cat .depend/hook.o.d 
    hook.o: hook.c cache.h git-compat-util.h compat/bswap.h wildmatch.h \
     banned.h strbuf.h hashmap.h hash.h repository.h path.h sha1dc_git.h \
     sha1collisiondetection/lib/sha1.h sha256/block/sha256.h list.h advice.h \
     gettext.h convert.h string-list.h trace.h trace2.h pack-revindex.h \
     oid-array.h mem-pool.h hook.h run-command.h thread-utils.h strvec.h
    [...]

I wanted to feed that into spatch somehow, but with e.g. --include it
will not include anything:

    ~/g/coccinelle/spatch.opt --sp-file contrib/coccinelle/strbuf.cocci --verbose-includes --no-includes --include cache.h --include path.h hook.c
    init_defs_builtins: /home/avar/g/coccinelle/standard.h
    HANDLING: hook.c

It seems that there's --recursive-includes, --all-includes,
--no-includes etc, but those all tweak different aspects of
auto-discover, or "seed" the auto-discovery via --include.

But I'd like a way to say "here, exhaustively, are my includes", does it
have such a mode? If not consider this a feature request.

Even better on top would be to further optionally tell it due die if it
ever encounters an include file that's not explicitly provided on the
command-line.

That would serve as a nice sanity check on the *.d files we get from
gcc/clang, and make sure that this way of optimizing its runtime works
as intended. I was planning to do that by parsing its output, but having
it as a native option would be easier.

Note: I probably don't *really* need this, since I can look at the *.d
file myself and have "make" determine if spatch needs to run at all, and
I trust the gcc/clang information well enough.

But being able to have spatch use that information exclusively would
also be nice, especially for the above mentioned sanity check.

Thanks!

             reply	other threads:[~2021-11-16 13:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16 13:27 Ævar Arnfjörð Bjarmason [this message]
2021-11-16 16:18 ` [cocci] Is there a --no-includes --but-includet-this foo.h --but-in[...] mode? Julia Lawall
2021-11-16 16:53   ` Ævar Arnfjörð Bjarmason
2021-11-16 17:04     ` Julia Lawall

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=211116.86lf1op65q.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=cocci@inria.fr \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.