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

[bruce.r.stephens at gmail.com]

Manuel Klimek <klimek-hpIqsD4AKlfQT0dZR+AlfA at public.gmane.org> writes:

> On Tue, Mar 12, 2013 at 11:26 AM,
> <bruce.r.stephens-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:

[...]

>> One possibility (which doesn't apply to DXR, which is a compiler plugin)
>> is producing a compilation database. Using LD_PRELOAD and stuff feels
>> yucky, and cmake is (to me) useless (the projects I care about mostly
>> don't use cmake).
>>
>
> Can you use ninja, which has recently grown the capability to throw out a
> compilation database?

I don't think so. We mostly use GNU Make, but also jam, scons (for some
bits of Swift), and bjam (for some boost libraries). Obviously
potentially we could use some unified (new) build system, but it doesn't
seem likely in the immediate future. What I have managed to do is get
DXR working (not trivial, since not all the builds allow overriding
CC/CXX).

> Can clang dump the relevant information in the right form? Feels like it
>> ought to be easy for it to do so, and that would surely be a clean way
>> to do it, presuming a project can be made to build with clang/clang++?
>> (Maybe it could be folded somehow with scan-build?)
>>
>
> Yes, it could be implemented in clang, but it's harder than doing it from a
> build-aware tool, as you'll need some cross-process synchronization,
> optimally in a OS-independent way...

I assume because clang might be being run several times in parallel (by
the build tool)?

That feels fixable, or at least a partial result feels useful enough to
have even if it would fail if run in parallel: have it write the
relevant rule for building foo.o to foo.o.json or something. Wouldn't
that kind of approach work, at least to a first approximation (maybe
needing paths mangling before combining all the rules or something)?

[...]