<div class="gmail_quote">On Wed, May 30, 2012 at 1:56 PM, Arnaud de Grandmaison <span dir="ltr"><<a href="mailto:arnaud.allarddegrandmaison@parrot.com" target="_blank">arnaud.allarddegrandmaison@parrot.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
On 05/28/2012 12:42 PM, Manuel Klimek wrote:
<blockquote type="cite">
<div class="gmail_quote">On Mon, May 28, 2012 at 12:25 PM, Arnaud
ALLARD DE GRANDMAISON <span dir="ltr"><<a href="mailto:arnaud.allarddegrandmaison@parrot.com" target="_blank">arnaud.allarddegrandmaison@parrot.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Manuel,<br>
<br>
For your information, I started the work on point #2 :
integrating compilation database in libclang + the
corresponding python binding.<br>
</blockquote>
<div><br>
</div>
<div>Awesome - feel free to cc me directly to any patches you
send out for review regarding this.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>/Manuel</div>
</div>
</blockquote>
<br></div>
Manuel,<br>
<br>
Here is a preliminary patch to let you know where I stand right now
as I will be away for a few days. It has the libclang c functions +
python bindings to export the CompilationDatabase functionality. It
is already usable with the python script attached.<br></div></blockquote><div><br></div><div>Cool!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Feel free to make any comments before I engage further down this way.<br>
<br>
A few remarks / questions :<br>
- no tests yet. For libclang, I intend to do it thru c-index-test
and provide a 'compile_commands.json' in test/Index. The JSON syntax
does not allow comments to be embedded inside, so I will probably
have to add a another file to manage the c-index-test call with lit.
For the python binding, I will enhance the attached python script.<br></div></blockquote><div><br></div><div>We actually throw the json file at a yaml parser. I don't think we should put that into the contract for the format, but for testing our implementation we can make use of the fact.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
- What is the invariant for class CompileCommand ? I understood from
the mailing list that CommandLine[0] is the compiler executable. Are
there any other ?<br></div></blockquote><div><br></div><div>There are none. The contract is that it contains the argv of whatever tool was executed to run the compilation. We just added support to add conversion functions. For example, we'll at least need to convert gcc command lines to clang command lines.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
- Error management : simplistic for now. Either aborts with a
hopefully useful message, or return a value which the caller is
expected to interpret correctly. Any thoughts on this ?<br></div></blockquote><div><br></div><div>I think an exception is more pythonic.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
- (not related to this patch) Would it make sense for CompileCommand
to provide a higher level interface for the CommandLine (at the C++
level). As a user of the CommandLine for a CompileCommand, I would
have expected an easy way to access easily (and separately) some
important parts of it : executable name (ok, that's the first
argument), input file and output file. This capture the fact that a
CommandLine is $(compiler) $(bunch_of_args) -o $(output) $(input)
and enable user to adapt to $(compiler) or mangle $(output) /
$(input) depending on the application's needs.</div></blockquote><div><br></div><div>I don't think it makes sense for CompileCommand. Getting out information means command line parsing. Now, if you ask whether we should have a standalone command line parsing class in clang, I'd say "yay!", but currently the only entity that can parse clang command lines is the driver when building up a compiler object.</div>
<div> </div><div>Apart from that:</div><div>- CompilationDatabase::loadFromDirectory(...) will support other ways than using compile_commands.json in the future - it is the major integration points for integrating with build systems; I'd rather have the comments say "for example" so we the comments don't get auto-out-of-date.</div>
<div><br></div><div> In general, the direction looks good.</div><div><br></div><div>Thanks!</div><div>/Manuel</div><div><br></div></div>