[cmake-developers] Extracting target metadata, IDE integration

[Tobias Hunger]

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.

>> On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly
>> <steveire at gmail.com> wrote:
>>>> The first is should this be run in a terminal or is this a GUI. Not
>>>> sure whether cmake has that information.
>>>
>>> CMake only knows whether the WIN32_EXECUTABLE property has been set on a
>>> target.
>>>
>>>  http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
>>>
>>> The property is harmless on non-Windows, so KDE sets it on non-Windows
>>> for gui applications IIRC, but others may not.
>>
>> This is a hint only.
>>
>> If it works correctly it is nice, otherwise the user will have to
>> toggle some checkbox
>> to change it to his or her liking.
>
> 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:-)

There is a overlap in what an IDE needs to know and what a build
system then needs to generate binaries, but it both also need some
information the other does not provide.

>> But why not have groups of sources?
>>
>> [
>>   "name": "testc1"
>>   "sourceGroups" [
>>      {
>>          "sources": [ "foo.cpp" ],
>>          "defines": ["BUILD_TEST=1", "QT_CORE_LIB", "EXTRA_FOO=1"],
>>          "includes": ["/opt/bat/include", "/usr/include/qt5"]
>>      },
>>      {
>>          "sources": [ "bar.cpp" ],
>>          "defines": ["BUILD_TEST=1", "QT_CORE_LIB"],
>>          "includes": ["/opt/bat/include", "/usr/include/qt5"]
>>      }
>>   ]
>> ]
>>
>> Would be simpler to parse for us.
>
> Perhaps. CMake already has a source group concept (for IDEs to group
> sources), and your concept of a source group here seems to be about grouping
> files with common includes/defines/build properties? The two concepts may be
> in conflict.

Right, my sourceGroups are sets of sources that have the same settings
applied to them.

I was coming from the CMAKE_EXPORT_COMPILE_COMMANDS output which does
have the information we need for the code model, but in a rather
inconvenient form. Having the files with similar flags/defines/etc.
grouped would make parsing them a lot faster. Not having to parse
compiler command lines would further improve things:-) So I am all for
you adding this information into some JSON file.

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.

> For comparison, does any other buildsystem require header listings like
> this? With qmake, I can populate HEADERS, but I don't have to (for headers
> which do not require moc).

I am aware that listing all headers is not necessary for the build
system. It is one of those things where the needs of an IDE and those
of a build system differ.

Qmake asks for the headers to be listed. So does Qbs, which we want to
be great for IDE integration. Both will most likely not notice if you
forget some, but they won't be listed in Creator then.

Best Regards,
Tobias