[cmake-developers] Extracting target metadata, IDE integration

[Aleix Pol]

On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
<Anton.Makeev at jetbrains.com> wrote:
> Hey everyone,
>
> We are developing CLion at JetBrains that utilizes CMake as its main project
> model. Stephen Kelly timely drew our attention to this discussion, and I’d like
> to share some thoughts. Here are the general ones and I’ll also comment on
> separate messages in the thread.
>
>
> We’ve managed to get almost all the necessary project information,
> using ‘GNU/MinGW Makefiles’ generators:
>
> * list of targets comes from 'CMakeFiles/TargetDirectories.txt'
> * list of source files from ‘CMakeFiles/A.dir/DependInfo.cmake’
> * list of headers and resources from ‘codeblocks.cbp’ file
> * per-file/target compiler and its flags from ‘CMakeFiles/Target.dir/flags.make’
> * location of product files from ‘CMakeFiles/Target.dir/build.make’
>
>
> What we miss (not all of them are directly related the targets metadata,
> but I'd like to share anyway since the topic is about IDE integration):
>
> * Location of every source file and target in CMakeLists
>   - it would greatly help to refactorings, navigation etc.
In the implementation I'm proposing, the target is specified. The file
is hard to figure out given that it's passed as a string argument and
it could come virtually from anywhere (i.e. glob, operations, a set()
somewhere else, etc.). My conclusion is that knowing the target
position is already a good enough help.

> * Complete list of headers and resource files
>   - they are only listed in special generators like code blocks.
I'll look into it, what do you need exactly? The headers in each target?

> * An easily parseable list of errors and warnings with origin information.
>   At the moment we parse error output but not everything can be parsed reliably.
Agreed, It's something we're missing as well. I also don't really like
the fact that sometimes the paths are absolute and sometimes they're
relative, especially in the relative case, since it's hard to tell if
it's relative to the build directory or source directory.

> * No progress indication. Since the generation may take several minutes,
>   providing feedback is crucial.
I never found such case, I would argue that a project which has a
cmake script that takes several minutes is broken, but maybe we can
open a thread to discuss it?

> * Ability to distinguish a library from an executable target.
>   This will help to offer a better UI for run/debug configurations.
It's included in the proposed implementation.

> * Possibility to collect information for every build target in one run.
>   Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately.
Well, that's because you use CodeBlocks generators. It seems like for
example in MSVC they generate many build configurations at once. This
implementation supports having parallel debug/release builds. Then we
can fix make/ninja generators or even create new ones.

> * CMake stops processing when it find a missing file, so that IDE cannot have
>   full project model, until this files is created.
Well, it's related to the error generation issue we discussed. I think
it's something we should discuss in parallel.

> * When there are existing in-source generated files in the project dir,
>   CMake doesn't allow generating into a separate out-of-source folder.
>   An IDE has to invent workarounds here.
Arguably, in-source generation is broken by definition...

> * Not sure if it’s possible at all - a lightweight phase where CMake only
>   collects necessary information (list of files/targets, compiler settings).
>   This will help IDE react to the changes much faster.
That would be extra-cool, agreed. Maybe it's an iteration we can
consider in the future.

>
>
> Here is why I think the discussed functionality should not be a separate
> generator:
>
> CLion doesn’t have it’s own project model nor is intended as build tool
> replacement. Currently, the only option for CLion users is makefiles build, that
> is not a best option for everyone: there is a good and fast alternative ‘Ninja’.
> Ideally, users should be able to choose whatever tool better suites them.
>
> The problem is that the generated Makefiles are used both, for internal needs,
> like reading project structure, and also to build and run the user’s program.
> If we wanted to support Ninja generator, we would need to rewrite all the logic
> that retrieves the project information, using the files that are created by
> Ninja generator. While I suppose it’s possible, it’s not the best option - very
> error prone and resource demanding.
>
> If CMake generated a separate descriptor, regardless the generator used
> (Makefiles, Ninja), it would be much easier to support; and the users will
> benefit from better, more reliable and faster CMake integration in an IDE.

I'd really appreciate your feedback on the patch I provided, I'll be
happy to provide the information you miss.

Aleix