<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">I wonder if enough of clang tidy functionality is exposed through libclang and python that you could do some clang-tidy-lite work with python tooling?</div><div dir="ltr"><br></div><div dir="ltr">I had some success extending libclang to power a language bindings generator (like SWIG)</div><div dir="ltr"><br><blockquote type="cite">On 26 Oct 2019, at 14:13, Robert Underwood via cfe-dev <cfe-dev@lists.llvm.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>
</p>
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-unicode">All,
<br>
<br>
tl;dr is there a way to use clang-tidy for small projects without
requiring users to rebuild most of clang/llvm provided versions
match?
<br>
<br>
Let me begin by offering my gratitude to the Clang/LLVM community
for the excellent C/C++ tools you all develop and we all benefit
from.
<br>
<br>
I'm a grad student who works on a number of small libraries that
use C/C++, and occasionally me or my colleagues change the APIs
for those libraries, and would like to provide tools to update to
the new APIs to our users. As I understand there are two main
options:
<br>
<br>
1. Write a new custom clang-tool to do the migrations
<br>
<br>
2. Reuse clang-tidy and write a new tidy-module or add our check
to an existing module.
<br>
<br>
The former has some disadvantages: it means that users now need to
run our tool and clang-tidy to get all of the fixes they need.
Additionally what we are doing with the migrations are essentially
what clang-tidy was designed to do.
<br>
<br>
The latter addresses these challenges, but presents a few more.
Now users have to compile and install a custom version of
clang-tidy in order to use our checks, and for various reasons the
user probably will compile and install a fair bit of the
clang/llvm ecosystem just to try our migration modules.
LLVM/clang/clang-tools-extra are not small projects and take a
while to compile and occupy substantial disk space once compiled
for a task like this.
<br>
<br>
I considered trying to write a module external to the LLVM/Clang
source tree and just link to the appropriate libraries in as I
have done with clang-tools in the past, but clang-tidy uses
several implementation specific headers that are not available
outside the clang-tools-extra source code repository (i.e.
ClangTidy.h). I recognize that this is not the [recommended
method for developing clang-tidy modules][1] so it doesn't
surprise me that this does not work.
<br>
<br>
However, I think there is a use case here. Not every project is
backed by Google, Intel, Apple, Sony, or another large company
with an extensive distributed build environment where rebuilding a
large amount of clang/llvm is more feasible. Not every clang-tidy
module needs to be up-streamed to clang-tidy especially those for
small libraries like mine.
<br>
<br>
I admit it is quite possible I am missing something, but I think
there should be a way to make this easier for small projects to
use. I've read the provided documentation several times, and I've
not found it.
<br>
<br>
I would appreciate your time and consideration as you consider
this request.
<br>
<br>
Respectfully,
<br>
<br>
Robert Underwood
<br>
<br>
<br>
[1]: <a class="moz-txt-link-freetext" href="https://clang.llvm.org/extra/clang-tidy/Contributing.html">https://clang.llvm.org/extra/clang-tidy/Contributing.html</a>
<br>
<br>
</div>
<span>_______________________________________________</span><br><span>cfe-dev mailing list</span><br><span>cfe-dev@lists.llvm.org</span><br><span>https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</span><br></div></blockquote></body></html>