[cmake-developers] Generating information for C++ tools in cmake (patch)

[Brad King]

Hi Manuel,

I think the goals of your work are important.  I like the general
idea.  One sure way to give such tools the same view of the code
as the compiler is to ask the build system to provide the information.

I'm a CMake developer but I also wrote gccxml.  The latter is a
code analysis tool that simulates the preprocessing performed by
a target compiler to get the same view of the code.  We use it to
convert C++ header files into a .xml representation of the interface
for easy loading by interpreted language wrapper generators.

In order to run gccxml in real projects we need to write CMake code
that uses add_custom_command to create build-time rules.  Passing
the include path and preprocessor definitions requires custom code
to add them to the command line, and there is no guarantee that they
stay in sync with what the real compiler gets.  This is difficult
to maintain.

One distinction between gccxml and tools like you propose is that
gccxml has to run during the build to help generate code for the
compiler rather than running after the build to analyze the code.
However, the difficulty with running it to match the compiler
demonstrates why build system awareness is helpful.

On 1/11/2011 5:10 PM, Manuel Klimek wrote:
> I thought about that, too. On the other hand, we might also want to
> make that information available from other generators where it makes
> sense - in my mind it is somewhat orthogonal to the generator:
> - for generators that are already very tightly IDE integrated (like
> VS) we probably don't need to output this information, as the IDE
> already exposes this information in well-defined ways that tool users
> for those IDEs would use
> - for generators that are not tightly coupled to the IDE or where the
> IDE doesn't make the build information easily accessible (like
> Eclipse), we actually want to enable developers to make the output
> "default" in their cmake build setup, so they can use command line
> tools or hand-made macros in their editor/IDE.

CMake has 2 categories of main generators: IDE and Makefile.  The
Xcode and VS generators are IDE, the rest are Makefile.  Other
generators like KDevelop are actually Makefile generators plus
project files that just list source files but not build rules.

The IDE generators (Xcode and VS) do not actually generate the
final compile lines.  Therefore the proposed functionality is
possible only with Makefile generators.  However, since there
is no toolchain not supported by Makefile generators that should
be sufficient.

> No, I'm not planning to output the link commands - this is purely for
> code understanding, not rebuilding the code - while thinking about how
> to enable fast rebuilds by adding this information might have some
> valid use case, it is currently completely out of scope as far as I'm
> concerned.

My understanding is that clang is based on llvm which is a set of
modular components for all parts of the toolchain.  It is conceivable
that tools in the future may be interested in the link line to do
whole-program analysis.  However, I think starting off with just the
compile information is sufficient.

> - you use your normal cmake+(your build system) workflow for building
> - you use tools that run over source files and use the little c++
> compile database to be able to understand the c++ code correctly
> 
> As a user, I want to be able to do both without having to run cmake in
> between. This might well be hidden behind a cmake configuration option
> if you think it affects the standard generation too much.

I need to review your patch in more detail before commenting on its
effects on standard generation.  If it is just a matter of writing
one extra file per logical target (created by add_executable,
add_library, or add_custom_target), then it shouldn't be too bad.

How do you propose to cover the new functionality in our test suite?

Currently your patch is one big change, but it looks like it factors
some existing code out into smaller pieces.  Do you mind splitting
it into multiple Git commits in a topic branch?  Ideally the first
commit(s) would just do the refactoring without changing behavior
and the later commit(s) would add the new functionality.  This level
of granularity in the commits will make your change easier to review.

Thanks!
-Brad