[cfe-dev] Producing compilation databases (was Re: Clang-based indexer and code navigator)

[bruce.r.stephens at gmail.com]

Laszlo Nagy
<rizsotto.mailinglist-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> writes:

> hi Bruce,
>
> you might have seen my tool, which trying to address the compilation
> database problem. (Just in case if you missed <
> https://github.com/rizsotto/Bear>) Which is using LD_PRELOAD to catch the
> compiler calls... And now I am wondering what does it mean 'feels yucky'?
> What other, more technical, point you have against it? ;)

I guess I was assuming there would have to be some system-specific
nastiness in order to get the appropriate information from the compiler
processes, but actually (now I look at it) the code looks really clean
(possibly because it's system-specific, but I'm using GNU/Linux so I
don't care about that). It happens to break for one case which I care
about (I've filed an issue).

[...]

> I got the feeling that putting this kind code into Clang would not solve
> the problem at all, but would Clang driver itself more complex...

It feels like it would add a teeny bit of complexity, yes.

> You still need to teach your build system to use Clang. And since you
> were able to do that, you can write a fake compiler, which only emit
> the message about it's command line arguments and generate a fake
> object file. (Of course you need to write fake ar/ld commands as well)
> But more importantly need a process which collect these messages and
> format into a JSON file.

Yes, maybe that's a better approach for what I was thinking about. That
would be even closer to the scan-build type approach. scan-build runs
the clang analyser and a real compiler, but it could just as well run
such a trivial tool and the real compiler.

In practical terms I feel having clang do it would be easier for me
because making the project compilable by clang (or other things) is
already a valuable goal (I want to be able to run the clang analyser,
apart from anything else).

[...]