[cmake-developers] Extracting target metadata, IDE integration

[Stephen Kelly]

Tobias Hunger wrote:

> Sorry, I am a bit late with replying to this... I do not follow this
> list too closely and got distracted by mails in between where I could
> not contribute anything:-/

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.

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

> 
>>> Secondly the linker flags would be nice to know. That way the
>>> LD_LIBRARY_PATH can be set correctly by the IDE so that all the
>>> libraries are found.
>>
>> If the linker flags were provided, you would have to parse them. Maybe a
>> runtimeLinkDirectories/linkDependentLibraries can be provided, similar to
>> the content passed to the option -rpath. I have no idea if similar
>> information can be acquired for MSVC/Windows. As Nils said, CMake might
>> not know the location of the import library.
> 
> If CMake knows the locations, then put them in, please.

I'm sure that won't be a problem.

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

>> Afaik, CMake does not know all the files included by your cpp files.
>> However, some buildsystems can add them to the list of sources if desired
>> for better IDE integration.
>>
>>  https://gitorious.org/grantlee/grantlee/commit/3eb40cf94
> 
> That is the big issue I have with CMake... it makes it impossible to use
> CMakeLists.txt as a sole source of project configuration.

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 want to know which files are part of the project and which are part
> of the current build.
> 
> At least Qt Creator does not need information on which conditions to
> be met for a file to become part of the current build.

Ok, good feedback, thanks.

Steve.