<div dir="ltr">On Tue, Mar 12, 2013 at 11:50 AM,  <span dir="ltr"><<a href="mailto:bruce.r.stephens@gmail.com" target="_blank">bruce.r.stephens@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Manuel Klimek <<a href="mailto:klimek-hpIqsD4AKlfQT0dZR%2BAlfA@public.gmane.org">klimek-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org</a>> writes:<br>

<br>
> On Tue, Mar 12, 2013 at 11:26 AM,<br>
</div>> <<a href="mailto:bruce.r.stephens-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org">bruce.r.stephens-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org</a>> wrote:<br>
<br>
[...]<br>
<div class="im"><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>
><br>
> Can you use ninja, which has recently grown the capability to throw out a<br>
> compilation database?<br>
<br>
</div>I don't think so. We mostly use GNU Make, but also jam, scons (for some<br>
bits of Swift), and bjam (for some boost libraries). Obviously<br>
potentially we could use some unified (new) build system, but it doesn't<br>
seem likely in the immediate future. What I have managed to do is get<br>
DXR working (not trivial, since not all the builds allow overriding<br>
CC/CXX).<br>
<div class="im"><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>
><br>
> Yes, it could be implemented in clang, but it's harder than doing it from a<br>
> build-aware tool, as you'll need some cross-process synchronization,<br>
> optimally in a OS-independent way...<br>
<br>
</div>I assume because clang might be being run several times in parallel (by<br>
the build tool)?<br>
<br>
That feels fixable, or at least a partial result feels useful enough to<br>
have even if it would fail if run in parallel: have it write the<br>
relevant rule for building foo.o to foo.o.json or something. Wouldn't<br>
that kind of approach work, at least to a first approximation (maybe<br>
needing paths mangling before combining all the rules or something)?<br></blockquote><div><br></div><div style>It would most certainly work. Somebody needs to put together a patch, and send it out :)</div><div style><br>
</div><div style>Cheers,</div><div style>/Manuel</div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[...]<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div></div>