[cfe-dev] CompilationDatabase support added to libclang and python binding

[Gregory Szorc]

On Mon, Jun 11, 2012 at 2:39 PM, Arnaud de Grandmaison
<arnaud.allarddegrandmaison at parrot.com> wrote:
>> First, some nits. I would change the source order of the declarations
>> so related APIs are grouped together then sorted from highest to
>> lowest level. Start with all the functions operating on
>> CXCompilationDb. Then define everything operating on
>> CXCompileCommands. Finally CXCompileCommand. This will increase
>> readability, IMO. Also, always place the "constructors" and
>> "destructors" next to each other and reference the other in the
>> doxygen blocks. This increases the chances that the destructors are
>> called appropriately.
> Yes. Things are in a bottom up order because I wanted each 'type' and
> its related functions to be grouped together. Doing things top down will
> force to split the type definition (usually void * for now) from its
> related functions, which I, as a developer, do not really like.

If you put all the typedefs before/away from the functions that
operate on them, I don't think that decreases readability. In fact,
I'd argue it increases it because you are describing all the "things"
(the data model) before you describe the actions that can be performed
on them. That's like reading a glossary before you dive into a
technical manual.

>> Everything is prefixed with "clang_tooling_." The "tooling" bit is new
>> to libclang. I personally like prefixing this way as it draws a clear
>> line between underlying modules. But, I know others feel differently
>> and may argue for its elimination. If we decide to keep it, perhaps a
>> new header, Tooling.h, would be the appropriate place to declare these
>> APIs since they are clearly separate from "index." This would extend
>> to the Python API as well.
> Also though about that. Although the tooling part is clearly a separate
> module, it will most probably be used together with the "index". So
> having a separate CTooling.h makes sense to me, but it should be made
> available to the users thru the Index.h. The same holds for the python
> binding. The Index acts more as an umbrella from which you can draw
> different submodules. Beside, some functionality from Index is reused :
> CXString for example.

I'm not sure it needs to be made available through Index.h. Sure, that
can be done easily enough. We could just as easily have Tooling.h
include Index.h (to get CXString, etc). Oh, bikeshedding.

>>>
>>> +    try:
>>> +        cmds = cdb.getCompileCommands('file_do_not_exist.cpp')
>>> +    except KeyError:
>>> +        assert True
>>> +    else:
>>> +        assert False
>>>
>>> You can do this?! I guess you do learn something new every day!
> What is surprising you there ? I am definitely not a python expert :)

I didn't know you could use "else" along with "except!" Sure enough,
it is documented at
http://docs.python.org/reference/compound_stmts.html#the-try-statement.
I'll have to start using that!