[cmake-developers] Extracting target metadata, IDE integration

[Tobias Hunger]

Hi Aleix,

On Tue, Mar 10, 2015 at 1:25 AM, Aleix Pol <aleixpol at kde.org> wrote:
> Thank you for taking some of your time.

Thank you for doing the work:-)

> On Sat, Mar 7, 2015 at 11:46 AM, Tobias Hunger <tobias.hunger at gmail.com> wrote:
>> How about adding some information on what this is you are actually
>> building here? CMake has the PROJECT command that does provide quite a
>> bit of information that could go here.
> I can look into that, I can see if I can extract the projects tree
> somehow and dispose them like it's doing with the targets.

>> Where are the sources this thing here is building? How were those
>> sources configured? CMake supports quite a few generators, so which
>> ones where used? Do I need to run ninja or make to build this (or
>> should I use "cmake build" anyway)?
> The sources are listed within the targets, separately for each
> configuration (as you can have different sources for debug builds and
> release).

No, which source directory was this created from? How was this build
configured (e.g. which compiler is used, which Qt version does it link
to, that kind of thing).

For qmake projects you can point to some directories that you built
when loading a project and that build is then imported into Qt
Creator. That is rather convenient as it can save a lot of time
rebuilding stuff just to make the IDE happy:-)

For that we need to sanity check: Is this indeed a build-directory of
the project we are opening? Which Kit (== configuration) was used to
generate that build?

> Regarding ninja/make, in KDevelop we just check if there's a
> rules.ninja file or a Makefile. Alternatively you can also check the
> CMAKE_GENERATOR value in the CMakeCache.txt. Or we can introduce it if
> you find it useful. I don't have a strong opinion there.

My -- maybe naive -- hope is that I can integrate cmake into an IDE
*without looking outside this json-file*.

I do not want to figure out which files are generated by which
generators, how those are structured internally or under which set of
conditions they may or may not be generated:-) Basically the less the
IDE needs to know about the cmake implementation (outside of the IDE
integration file) the more robust the support can be.

>> Creator does allow existing qmake builds to be imported and that kind
>> of information does help a lot with that functionality.
>>
>>> "dependencies" :
>>> [ "/home/kde-devel/tmp/llvm/build/CMakeFiles/3.2.20150306-g139588/CMakeSystem.cmake", "/lots/more/files", ... ]

What does that tell me? That file is even in the build directory, so
it is most likely not the CMakeLists.txt you built. There are also
more than one CMakeLists.txt in that file, so which one is "the one"?

And there is no hint as to how the project is configured... That is
probably available in CMakeCache.txt, but again, ideally I would not
need to know about that file.

>>>    "configs" :
>>>    [
>>>        {
>>>            "name" : "",
>>
>> Why is the name empty?
> Because it was built without specifying any name. (i.e. it didn't pass
> -DCMAKE_BUILD_TYPE=...).

There is no default for CMAKE_BUILD_TYPE?

>>>            "sources" : [ "/list/of/cpp/files, ]
>>
>> Any way to also get the headers? Do you see any option to hint where
>> new sources would need to be added to make them a part of this target?
> I looked into how the CodeBlocks did it to provide the header files.
> It's just brute-forcing to see if the file renamed to *.h/*.hpp/*.hxx
> is present.
> CMake doesn't have this kind of information, so I think it's better
> that the IDE's do the hacky parts than cmake.

A list of *all* headers used during the building of the target would
be fine. There is no need to filter that list down in any way.

CMake has that information: Without it cmake could not possibly know
when a cpp file needs rebuilding. It would not be as successful a
build system when it did not know that:-)

> Also we don't really have information about where to put them. You can
> use the minimum common denominator among the sources I guess.

I don't understand that part, sorry.

>>
>>>        }
>>>    ],
>>>    "installed" : "true",
>>
>> I guess this means "make install" will install it. Where will this file end up?
> Yes. I tried to figure it out but didn't manage to find the correct
> way to query it. I can try harder. :D
>
>>
>>>    "name" : "LLVMPowerPCInfo",
>>>    "output_directory" : "/home/kde-devel/tmp/llvm/build/lib/Target/PowerPC/TargetInfo",
>>
>> For what is the output directory relevant? The output above does
>> implicitly list that already, doesn't it?
> It's important in case the output path is overriden, see last e-mail
> by Alexander Neundorf.
>
>>
>>>    "type" : "STATIC_LIBRARY"
>>
>> Which types are possible here?
> It's an enum internal to cmake. At the moment:
> EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY,
> OBJECT_LIBRARY, UTILITY, GLOBAL_TARGET, INTERFACE_LIBRARY,
> UNKNOWN_LIBRARY.
>
>>
>>> },
>>
>>
>> There is a lot of useful information here! Thanks for pushing into
>> this direction. I am sure this will help a lot.
>>
>> Ideally this file would be enough to provide all information we need
>> as an IDE to:
>>
>> * Present the project structure as seen by the build system.
>> * Generate the code model
>> * Build the project
>> * Deploy the project
>> * Run and debug parts of the project
>> * Adding and removing files to a project
>>
>> For the project structure this does help: It provides us with a list
>> of all the build targets, which is already nice. CMake does support
>> more structure with Projects and subprojects IIRC and that information
>> is lost. Would it be much work to get that information back?
> as discussed above, I'll look into that next thing.

I am a cmake noob, but maybe I can help?

>> For the code model this is not much help at all: There is no
>> information on compiler used, include directories nor Defines or
>> compiler flags. Where am I supposed to get that information from? Do I
>> need to generate and parse the list of commands run and extract that
>> information from there? Having that information available right in the
>> sources array of each target would be so much more convenient and
>> would also make IDE integration so much easier: You would need to know
>> about one file only and won't need to figure out several.
> We can do that, I mentioned earlier in this thread that currently
> we're using compile_commands.json for that (
> CMAKE_EXPORT_COMPILE_COMMANDS).
>
> I agree it could be interesting to add it. In other words, if nobody
> disagrees, I'll add it although I see how this will make the output
> grow a lot.

I found parsing of compiler commands non-trivial: It gets messy when
some file gets built twice, especially when different defines, etc.
are set at the different times. E.g. once it is built with
-DENABLE_TEST by some unit test and once it is built without any flags
by the normal application.

Best Regards,
Tobias