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

[Laszlo Nagy]

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? ;) Was testing
against: scons, GNU make, qmake, cmake, bash... and it works reliable most
of the cases. On solaris/BSD systems, you could use D-Trace, which also
capture all exec calls, more easy. But that's another platform specific
solution.

My conclusion was at that time, I either write OS specific solution, which
works on any build system. Or write build-tool specific solution, which
works on every OS. Since I'm interested in sources which are compiles on
Linux, I went for the LD_PRELOAD trick.

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... 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. (By the way this
is exactly what the LD_PRELOAD solution is doing, except no need for fake
compiler/linker. And no need to put code into Clang.)

Regards,
Laszlo


On Tue, Mar 12, 2013 at 7:26 PM, <bruce.r.stephens at gmail.com> wrote:

> Sean Silva <silvas-olO2ZdjDehc3uPMLIKxrzw at public.gmane.org> writes:
>
> [...]
>
> > We seem to have a proliferation of Clang-based source navigators (DXR,
> > woboq, and now SourceWeb). It would be really great if you could get
> > in contact with the authors of these other tools (I see Oliver Goffart
> > is already in this thread) and discuss what kinds of issues you ran
> > into when developing the respective tools (you probably want to
> > contact jcranmer for DXR); if there appear to be some common issues,
> > it would make sense to get that information upstream so that we can
> > fix/improve the situation. It would probably be sufficient to send a
> > mail to cfe-dev CC'ing them.
>
> Agreed. I'm not sure that there will in fact be much overlap, but if
> there is, it would be good to move it upstream. (I'm basing that on
> playing with DXR's plugin, which seems fairly lightweight, as these
> things go.)
>
> 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 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?)
>
> > Also, if there is enough common ground between your objectives, it
> > would be really cool if we could pool effort and develop a solution on
> > trunk in clang-tools-extra: and then dogfood it! I've been wanting a
> > better source navigator than Doxygen's source listings for a while
> > now, and I think it would be appreciated.
>
> It would be neat to have that available alongside the doxygen API docs.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130314/9a06ab69/attachment.html>