<div dir="ltr">hi Bruce,<div><br></div><div style>you might have seen my tool, which trying to address the compilation database problem. (Just in case if you missed <<a href="https://github.com/rizsotto/Bear">https://github.com/rizsotto/Bear</a>>) 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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.)</div>
<div style><br></div><div style>Regards,</div><div style>Laszlo</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 12, 2013 at 7:26 PM,  <span dir="ltr"><<a href="mailto:bruce.r.stephens@gmail.com" target="_blank">bruce.r.stephens@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sean Silva <<a href="mailto:silvas-olO2ZdjDehc3uPMLIKxrzw@public.gmane.org">silvas-olO2ZdjDehc3uPMLIKxrzw@public.gmane.org</a>> writes:<br>

<br>
[...]<br>
<br>
> We seem to have a proliferation of Clang-based source navigators (DXR,<br>
> woboq, and now SourceWeb). It would be really great if you could get<br>
> in contact with the authors of these other tools (I see Oliver Goffart<br>
> is already in this thread) and discuss what kinds of issues you ran<br>
> into when developing the respective tools (you probably want to<br>
> contact jcranmer for DXR); if there appear to be some common issues,<br>
> it would make sense to get that information upstream so that we can<br>
> fix/improve the situation. It would probably be sufficient to send a<br>
> mail to cfe-dev CC'ing them.<br>
<br>
Agreed. I'm not sure that there will in fact be much overlap, but if<br>
there is, it would be good to move it upstream. (I'm basing that on<br>
playing with DXR's plugin, which seems fairly lightweight, as these<br>
things go.)<br>
<br>
One possibility (which doesn't apply to DXR, which is a compiler plugin)<br>
is producing a compilation database. Using LD_PRELOAD and stuff feels<br>
yucky, and cmake is (to me) useless (the projects I care about mostly<br>
don't use cmake).<br>
<br>
Can clang dump the relevant information in the right form? Feels like it<br>
ought to be easy for it to do so, and that would surely be a clean way<br>
to do it, presuming a project can be made to build with clang/clang++?<br>
(Maybe it could be folded somehow with scan-build?)<br>
<br>
> Also, if there is enough common ground between your objectives, it<br>
> would be really cool if we could pool effort and develop a solution on<br>
> trunk in clang-tools-extra: and then dogfood it! I've been wanting a<br>
> better source navigator than Doxygen's source listings for a while<br>
> now, and I think it would be appreciated.<br>
<br>
It would be neat to have that available alongside the doxygen API docs.<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>