[cmake-developers] Extracting target metadata, IDE integration

[Stephen Kelly]

Anton Makeev 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.

Thanks!

> * Location of every source file and target in CMakeLists
>   - it would greatly help to refactorings, navigation etc.

Ok, that seems to already be part of the current design/implementation.

> * Complete list of headers and resource files
>   - they are only listed in special generators like code blocks.

That generator guesses that if foo.cpp is in the project and foo.h exists, 
then foo.h must also be part of the project:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmExtraCodeBlocksGenerator.cxx;h=56a6edbb;hb=HEAD#l449

That might not be true, but you can probably make the same guess inside 
CLion anyway?

> * 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.

That non-reliability of parsing that stuff might be something to file bugs 
about. I think it's out of scope of the metadata file design.

> * No progress indication. Since the generation may take several minutes,
>   providing feedback is crucial.

There is feedback during the configure stage, and as the generation stage 
may take longer as of the last few releases, I have thought that showing 
some progress could be worthwhile. I haven't looked into it though. I filed

 http://public.kitware.com/Bug/view.php?id=15172

to track the idea.

Again though, this is out of scope of the target metadata file.

> * Ability to distinguish a library from an executable target.
>   This will help to offer a better UI for run/debug configurations.

This is already part of the current design/implementation.

> * Possibility to collect information for every build target in one run.
>   Currently, we have to invoke generator for every CMAKE_BUILD_TYPE
>   separately.

This is part of the updated design.

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11041

> * CMake stops processing when it find a missing file, so that IDE cannot
> have
>   full project model, until this files is created.

True. However, if cmake stops processing (because of a missing file or many 
other reasons, such as a missing dependency), the full project model is not 
known. I'm not sure this is 'fixable'.

> * 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.

I'm not sure CMake can provide a better solution to this. Would you want to 
run cmake in a mode which clears out such files somehow? I'm not sure that 
would be accepted.

> Here is why I think the discussed functionality should not be a separate
> generator:

I think that ship has sailed. The feature is being implemented with a 
variable for control, not a generator.

Thanks for the feedback!

Steve.