[cmake-developers] Extracting target metadata, IDE integration

Anton Makeev Anton.Makeev at jetbrains.com
Thu Sep 25 03:14:38 EDT 2014


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.
* Complete list of headers and resource files 
  - they are only listed in special generators like code blocks.
* 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.
* No progress indication. Since the generation may take several minutes, 
  providing feedback is crucial.
* Ability to distinguish a library from an executable target. 
  This will help to offer a better UI for run/debug configurations.
* Possibility to collect information for every build target in one run. 
  Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately.
* CMake stops processing when it find a missing file, so that IDE cannot have 
  full project model, until this files is created.
* 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.
* 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.


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.


Regards,
Anton Makeev




More information about the cmake-developers mailing list