[cfe-dev] Getting involved with Clang refactoring

[Manuel Klimek]

On Thu, May 24, 2012 at 11:39 PM, James K. Lowden
<jklowden at schemamania.org>wrote:

> On Tue, 22 May 2012 15:49:42 +0200
> Manuel Klimek <klimek at google.com> wrote:
>
> > > Gentlemen, could you tell me please what you mean by a "compilation
> > > database"?  It sounds like a list of files to compile, something I'd
> > > normally look to make(1) to provide.  Apparently that's not what you
> > > mean, or there's some reason make won't do the job.
> > >
> > > If I understood the problem better perhaps there's something I
> > > could do about it.
> >
> > The problem with make is that it executes the compiler based on
> > changes in the dependency graph.
> >
> > Imagine you want to run a tool on all files that use a specific
> > symbol. To do this you need to:
> > 1. figure out the compile command line for the file into which you're
> > pointing to figure out the symbol under the cursor
> > 2. run the tool over all files that reference that symbol
>
> 3.  In an order determined by the dependency graph.  :-)
>

No, in one process at the same time.


> Thank you for the explanation.  At least now I partly understand what
> you're talking about.
>
> But I'm still puzzled.  Why would one need to recompile all files that
> use a specific symbol? Changes to a symbol normally occur in a header
> file, affecting the dependency graph in just the way that makes make
> useful.  To solve the problem you describe -- to have Clang recompile
> "all files that use a specific symbol"  -- one could touch(1) all such
> files and then run make.
>

Not all build systems work on system time. Some work on content digests.
Even if this worked, the amount of stats that build systems do in
ReallyLargeCodeBases to figure out what to build can be a huge cost, and
can actually dwarf the time it takes to reparse 3 or 4 files you care about.

And there's one more reason: for example, I want to rename some symbol. I
need all files to parse before the refactoring and after the refactoring,
as broken files lead to problems in the AST.


> The "figure out the command line" part is also intrinsic to make, as
> you know, based on the filename suffix.  That's 30 years of prior art
> that the compilation database seems to be reinventing.
>

I think this argument is way to generic. It seems to me like most
innovations look like this at first. I might be wrong, but at least let me
try ;)


> I understand the project has an existing build infrastructure, and that
> the compilation database is already embedded in it.  It's not yet clear
> to me why it was invented, and whether it's a solution or a problem.
>

It was definitely invented by multiple people independently in different
shades:
For example, look at how clang-complete works - it requires you to have a
simplified compilation database (one compile command that works for all
files you work with) in your project. This does not work for a large set of
projects, though.

Cheers,
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120525/cbc20aa7/attachment.html>