[cmake-developers] Extracting target metadata, IDE integration

Stephen Kelly steveire at gmail.com
Mon Oct 20 13:15:34 EDT 2014


Tobias Hunger wrote:

> Hey Stephen,
> 
> On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly
> <steveire at gmail.com> wrote:
>> No problem, thanks! I recently discovered that Creator makes fragile
>> guesses about source files and targets
>>
>> https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified
>>
>> so I would really like to create a solution which makes that unnecessary.
> 
> I am no expert on this part of the codebase, but I would not be
> surprised if it did do some stupid things when seeing cmake. We do not
> support that too well.

What I mean is: the problem seems to be that source files are not listed 
per-target in the codeblock files CMake generates, so creator is forced to 
guess. I don't know if better information can be put into the C::B files, 
but I think the proposed json file is a better solution anyway. I don't 
generally like that creator (and clion) have to rely on parsing a foreign 
generators files.

>> Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac
>> Bundle stuff the gui/console distinction doesn't really fit into the
>> buildsystem. Maybe such a checkbox, pre-populated with the hint, is
>> needed anyway.
> 
> Not into a build system, but into an IDE:-)

Yes, I wrote 'doesn't fit into the buildsystem' - implying it fits into the 
IDE, maybe in the form of a checkbox.

> I do not think there is a conflict between CMake source groups and
> what I was referring to, except maybe in my poorly chosen name.

I was thinking about a case where the source groups defined in 

 http://www.cmake.org/cmake/help/v3.0/command/source_group.html

commands would be exported in the JSON. I don't know if that's a good idea 
or not, but if it is, then yes, namespacing may be the only issue.
 
Thanks,

Steve.





More information about the cmake-developers mailing list