[cmake-developers] Review request: Ninja-EXPORT_COMPILE_COMMANDS

[Manuel Klimek]

+erikjv, who might have the perspective of yet-another-meta-build-system :)

On Thu, May 10, 2012 at 12:47 AM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> On Sun, May 06, 2012 at 03:20:59PM +0200, Stephen Kelly wrote:
>>
>> Hi,
>>
>> I've pushed a new branch to my clone for review to make the
>> CMAKE_EXPORT_COMPILE_COMMANDS option work with the Ninja generator.
>>
>> https://gitorious.org/~steveire/cmake/steveires-cmake
>>
>> Thanks,
>>
>> Steve.
>
> Hi Steve,
>
> Thanks for working on this.
>
> I think the main problem with your changes is that they do not respect
> the CMAKE_*_COMPILE_OBJECT variable, so the output will be wrong for
> non-C++ compilers or compilers that do not take the conventional set
> of command line parameters.
>
> Furthermore, there is no need to make paths within the build directory
> absolute.  Each command must be invoked from the home output directory
> (i.e. the build "root" directory), so each command's "directory"
> attribute should be set to that directory, rather than the start
> output directory as in your patch.
>
> I am not sure if this is the best approach for building JSON files
> from Ninja CMake builds.  A few weeks ago I spoke with the folks at
> Google who are working on Clang tooling, and I believe the current
> thinking is that it may be best to teach Ninja to output JSON files
> based on the provided build.ninja files.  The advantage of this is
> that it will work for any build system with a Ninja generator, and
> there would be no need to add functionality to CMake which may impose
> an additional maintenance burden and get out of sync with the
> "real" build commands.

As far as I recall we didn't come to a conclusion of what the "right"
way to do it is, so let me try to summarize the thoughts we had first.

With meta-build systems being common, there are basically 3 options
for how to export build related information in a standardized format
that is independent of the target build system:

1. Implement the output in every target build system
Pro:
- there might be implicit knowledge about the build that only the
target system has
- the format can be produced even when you don't have a meta build system
Con:
- some target build systems are hard to extend (make, VS, etc)
- there are more target build systems then meta-build-systems

2. Implement the output in every meta build system
Pro:
- good meta build systems like cmake can abstract out common code for
different target build systems, so there's less code to maintain
overall
- there are fewer places to implement the format
Con:
- not usable without meta build systems

3. A combination:
Add support to some target build systems (like ninja) to support the format.
Add support to meta build systems to output the format themselves for
targets that don't support it, and add implicit targets to reproduce
the information in the right spots for target build systems that
support it.

I think (3) is the optimal solution - target build systems can opt in
to support the format, thus making use of their implicit knowledge
about the build, while meta-build systems can ensure that no target
system is left behind, using the common infrastructure to give basic
support with little code.

>From that perspective, I would argue that the proposed patch is a good
thing (as it is not a lot of code and supports a real current pain (at
least for me)), but we might want to rip it out once ninja supports
compile command output itself.

Thoughts?
/Manuel