[cfe-dev] Getting involved with Clang refactoring

[Manuel Klimek]

On Wed, May 30, 2012 at 1:56 PM, Arnaud de Grandmaison <
arnaud.allarddegrandmaison at parrot.com> wrote:

>  On 05/28/2012 12:42 PM, Manuel Klimek wrote:
>
> On Mon, May 28, 2012 at 12:25 PM, Arnaud ALLARD DE GRANDMAISON <
> arnaud.allarddegrandmaison at parrot.com> wrote:
>
>> Hi Manuel,
>>
>> For your information, I started the work on point #2 : integrating
>> compilation database in libclang + the corresponding python binding.
>>
>
>  Awesome - feel free to cc me directly to any patches you send out for
> review regarding this.
>
>  Cheers,
> /Manuel
>
>
> Manuel,
>
> 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.
>

Cool!


> Feel free to make any comments before I engage further down this way.
>
> A few remarks / questions :
> - 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.
>

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.


> - What is the invariant for class CompileCommand ? I understood from the
> mailing list that CommandLine[0] is the compiler executable. Are there any
> other ?
>

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.


> - 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 ?
>

I think an exception is more pythonic.


> - (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.
>

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.

Apart from that:
- 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.

 In general, the direction looks good.

Thanks!
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120530/8430d6fe/attachment.html>