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

[Manuel Klimek]

Answering what Stephen didn't reply to yet :)

On Wed, Jun 13, 2012 at 11:44 AM, David Röthlisberger <david at rothlis.net>wrote:

> On 12 Jun 2012, at 19:04, Manuel Klimek wrote:
> >
> > http://clang.llvm.org/docs/JSONCompilationDatabase.html
> >
> > Feeback or patches welcome :)
>
> Thanks Manuel -- that was quick!
>
>
> SUPPORTED SYSTEMS
>
> * Since which version of CMake?
>

Added to the doc.


>
> * Give an example of how to add the option to a CMakeLists.txt, and how
>  to specify the option on the command-line when not present in the
>  CMakeLists.txt.
>

As Stephen said, this is a core cmake option if the generator supports it,
so I'm not sure putting more cmake docs in here would help.


>
> * Out of curiosity, how hard would it be to implement for other CMake
>  targets (like Visual Studio projects) -- presumably the compilation
>  command would be different, but everything else can be re-used?
>

I don't know how much sense this makes before we have more windows stuff
working in clang.
It most certainly is possible, and I'm happy to advise should somebody be
interested in tackling it...


> * Perhaps give a link to the specific CMake implementation for the sake
>  of those considering adding support for other CMake targets:
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe07b055
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5674844d


I don't think that would help that much. The CMake folks usually cc' me
into discussions, which I think is much more helpful. In general, the
concepts are really simple here.


>
> FORMAT
>
> Pick a name: "compile object" or "command object", and use it consistently:
>
> --- JSON Compilation Database Format Specification.html.orig
> +++ JSON Compilation Database Format Specification.html
> @@ -111 +111 @@
> -objects, where each object specifies one way a translation unit
> +"command objects", where each command object specifies one way a
> translation unit
> @@ -113 +113 @@
> -<p>Each object contains the translation unit's main file, the working
> +<p>Each command object contains the translation unit's main file, the
> working
> @@ -131 +131 @@
> -compile objects for the same file, for example if the same translation
> unit is
> +command objects for the same file, for example if the same translation
> unit is
>
> If you have 2 different compilation commands for the same source file, do
> you
> have:
> a. 2 separate "command objects", or
> b. a single command object with two "command" entries?
>
> With my above wording changes, the answer is unambiguously "b"; but I
> want to confirm that's actually what you intended. Actually with json
> it's probably impossible to have the same key twice so I think I've just
> answered my own question.
>
>
> MINOR FIXUPS
>
> --- JSON Compilation Database Format Specification.html.orig
> +++ JSON Compilation Database Format Specification.html
> @@ -78 +78 @@
> -<p>This document describes a format to specify how to replay
> +<p>This document describes a format for specifying how to replay
> @@ -82 +82 @@
> -<p>Tools based on the C++ AST need full information how to
> +<p>Tools based on the C++ Abstract Syntax Tree need full information how
> to
> @@ -102 +102 @@
> -<p>Currently <a href="http://cmake.org">CMake</a> support generation of
> compilation
> +<p>Currently <a href="http://cmake.org">CMake</a> supports generation of
> compilation
> @@ -131 +131 @@
> -compile objects for the same file, for example if the same translation
> unit is
> +compile objects for the same file, for example if the same source file is
>
> Justification for the 2nd change: Documentation aimed at users of
> clang-based
> tools shouldn't contain acronyms relating to compiler internals.
>
> Justification for the 4th change: If the build configuration has changed
> (different -D or -I command-line options) then it isn't really the same
> translation unit.
>

Applied all your patches and submitted.

Thanks a lot for your feedback :)

Cheers,
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120613/7804e6fe/attachment.html>