<div dir="ltr"><div dir="ltr">On Tue, Apr 28, 2020 at 3:09 AM Artem Dergachev via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey!<br>
<br>
1. I'm glad that we're finally trying to avoid dumping PCH-s on disk!<br>
<br>
2. As far as I understand, dependencies are mostly about Clang binary <br>
size. I don't know for sure but that's what I had to consider when I was <br>
adding libASTMatchers into the Clang binary a few years ago.<br>
<br>
3. I strongly disagree that JSON compilation database is "just right for <br>
this purpose". I don't mind having explicit improved support for it but <br>
I would definitely prefer not to hardcode it as the only possible <br>
option. Compilation databases are very limited and we cannot drop <br>
projects or entire build systems simply because they can't be <br>
represented accurately via a compilation database. So I believe that <br>
this is not the right solution for CTU in particular. Instead, an <br>
external tool like scan-build should be guiding CTU analysis and <br>
coordinate the work of different Clang instances so that to abstract <br>
Clang away from the build system.<br></blockquote><div><br>What functionality do you picture the scan-build-like tool having that couldn't be supported if that tool instead built a compilation database & the CTU/CSA was powered by the database? (that would separate concerns: build command discovery from execution, and make scan-build-like tool more general purpose, rather than specific only to the CSA)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 4/28/20 11:31 AM, Endre Fülöp via cfe-dev wrote:<br>
><br>
> Hi!<br>
><br>
> Question:<br>
><br>
> Why is the dependency on ClangTooling ill-advised inside ClangSA (also <br>
> meaning the Clang binary) itself ?<br>
><br>
> Context:<br>
><br>
> Currently I am working on an alternative way to import external TU <br>
> AST-s during analysis ( <a href="https://reviews.llvm.org/D75665" rel="noreferrer" target="_blank">https://reviews.llvm.org/D75665</a> ).<br>
><br>
> In order to produce AST-s, I use a compilation database to extract the <br>
> necessary flags, and finally use ClangTool::buildAST.<br>
><br>
> I am aware that I have other options for this as well (like manually <br>
> coding the compdb handling for my specific case for the<br>
><br>
> first step, and maybe even dumping ASTs as pch-s into an in-memory <br>
> buffer), but still consuming JSONCompilationDatabase<br>
><br>
> is just too convenient. I would not want to introduce another format <br>
> when compilation database is just right for this purpose.<br>
><br>
> Elaboration:<br>
><br>
> While I understand that introducing dependencies has its downsides, <br>
> but not being able to reuse code from Tooling is also not ideal.<br>
><br>
> I would very much like to be enlightened by someone more familiar with <br>
> architectural decision already made why this is the case,<br>
><br>
> and optionally how I could proceed with my efforts so that I can come <br>
> up with the most fitting solution i.e. not a hack.<br>
><br>
> Thanks,<br>
><br>
> Endre Fülöp<br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>